Elsewhere

OpenLucius: Why the Bootstrap HTML framework in Drupal & OpenLucius

Planet Drupal - Thu, 29/01/2015 - 17:58

The Bootstrap HTML framework in Drupal, we love it. That's why we build the front-end of Drupal distribution OpenLucius with it. So we love it, but why is that?

There are alternatives to integrate in Drupal websites. Below we will give you a few reasons why we currently prefer the Bootstrap framework.

Why a HTML framework

First of all, why should you use a HTML framework? These possibilities also exist:

Categories: Elsewhere

Holger Levsen: 20150129-reproducible-fosdem

Planet Debian - Thu, 29/01/2015 - 17:16
Bit by bit identical binaries coming to a FOSDEM near you

Tomorrow I'll be going to FOSDEM because of the rather great variety of talks, contributors and beers - and because even after 10 years I still love to see the Grand Place at night!

On Saturday afternoon I'll be giving a talk titled "Stretching out for trustworthy reproducible builds - the status of reproducing byte-for-byte identical binary packages from a given source". I'm pretty thankful to the FOSDEM organisers for accepting this talk despite me submitting it rather (too) late, which was mostly due to the rapid developments in recent times. These are exciting times indeed: it'll be an opportunity to present what we did, how we did it, the progresses we had so far, our findings, and our plans for the future. The interview by the FOSDEM organizers might give you some preliminary insights, but you should come if you can!

So, please spread the word: this talk not at all only about Debian. We hope to have many upstream software developers and maintainers from other distributions attending as we will explain how reproducible builds are about reliability in software development and deployment in general. We hope one day reproducibility will be the norm everywhere and thus we want to reach out to upstreams and other distros now.

And it's getting even better: I learned a very pleasant surprise yesterday: I won't be giving this talk alone but rather together with Lunar! I would have gladly given this talk alone as planned, but team work is soo much more fun - and more productive too as this very project is showing everyday!

Categories: Elsewhere

InternetDevels: Drupal tourists in Ternopil

Planet Drupal - Thu, 29/01/2015 - 11:31

Nothing keeps Drupal tourists from spreading the word! We are passionate for Drupal and IT, so enjoy meeting like-minded people very much! Despite the cold winter weather, Ternopil welcomed us with warmth and friendliness. How was it? Our blog post will tell.

We were getting ourselves ready for the ride for almost a month. Our brandy Drupal van wanted to make nice impression too, that’s why the journey hit off from the car wash :)

Read more
Categories: Elsewhere

Craig Small: Juniper Firewalls and IPv6

Planet Debian - Thu, 29/01/2015 - 07:49

I found an interesting side-effect of the Juniper firewalls when you introduce IPv6.  In hindsight it appears perfectly reasonable but if you are not aware of it in the first place you may have a much more permissive firewall than you thought.  My setup is such that my internet address changes every time I connect to an ISP. I have services “behind” the Juniper that I want to expose onto the Internet, in this case a mailserver.

Most of the documentation states to have a reasonably open firewall rule and a nat rule.

[edit security nat] destination { pool mailserver-smtp { address 10.1.1.1/32 port 25; } } [edit security policies] from-zone Internet to-zone Internal { policy Mailserver { match { source-address any; destination-address any; application smtp; } then { permit; } } }

Pretty standard stuff and its documented in plenty of places. We cannot set a destination address because its dynamic, so set it to all.  My next step was, ok my mailserver is on IPv4 and IPv6, how do I let the IPv6 connections in?

Any means ANY

That’s where I noticed I had a problem, they could already get in. In fact anyone could get to the mailserver (good) and anything else that had an open SMTP port on my network and used IPv6 (bad). It seems that any destination address means ANY IPv4 or IPv6 address.  Both myself and the writers of the documentation hadn’t initially thought of what happens when you add IPv6.

The solution is to not let any destination, but any IPv4 and the specific mailserver destination. First create an addressbook entry for the IPv6 address of the mailserver.

[edit security address-book global] address mailserver-ipv6 2001:Db8:1111:2222::100/128;

 

then adjust the rule

[edit security policies] from-zone Internet to-zone Internal { policy Mailserver { match { source-address any; destination-address [ any-ipv4 mailserver-ipv6]; application smtp; } then { permit; } } }

That way there is access to the mailserver using either IPv4 or IPv6.  I’m also going to try to see if I adjust the rule so the destination only includes the mailserver address (both IPv4 and IPv6) even though the IPv4 is NATed and see if that works.

 

Categories: Elsewhere

Mediacurrent: SprintWeekend2015: A review of Mediacurrent's participation

Planet Drupal - Thu, 29/01/2015 - 00:24

While we at Mediacurrent have been trying to bring internal focus and organization to our contributions, the rest of the Drupal community was planning a “Sprint Weekend” for January 17th and 18th.

Categories: Elsewhere

Web Wash: How to Use Display Suite Field Templates in Drupal 7

Planet Drupal - Wed, 28/01/2015 - 22:36

Display Suite is one of the essential modules which I use on every project. It allows you to change the look and feel of entity bundles, i.e., content types, vocabularies, users and much more. Building custom layouts and adding fields is a breeze, but there's another feature you may not be aware of and that's custom field templates. Display Suite allows you to change the markup which is used to render individual fields.

The functionality to change field templates is off by default. To turn it on, you'll need to enable the "Display Suite Extras" sub-module and check the "Field Templates" on the Extras page.

In this tutorial, you'll learn how to enable "Field Templates" and how to use them.

Categories: Elsewhere

Phase2: Finding (and Retaining) the Best of the Best

Planet Drupal - Wed, 28/01/2015 - 22:13

Yesterday, Phase2’s own Chris Bloom was featured on the Drupal Association’s podcast on how to hire great Drupal talent. It’s a pertinent conversation to have at the moment, when 92% of hiring managers surveyed by the Drupal Association reported that there is insufficient Drupal talent in the market to meet their needs.

Over the course of an hour, Chris, Randi King, and Mike Lamb shared many insights on not only attracting talent, but keeping it around. I highly recommend giving the podcast a listen once the recording is available on the Association’s website. In the meantime, as Phase2’s Talent Manager, I wanted to elaborate on some of our company’s methods for finding, hiring, and retaining the best of the best in Drupal and beyond.

Finding Talent: Emphasizing Relationships

Because we operate in an industry of web professionals, it may be a little surprising that the majority of Phase2’s recruiting happens organically, not digitally. True, online advertising plays a role, and we share open positions on our website, LinkedIn page, and Twitter. However, many of our new hires are discovered by employee referrals and face-to-face introductions at community events and job fairs. This is no coincidence: we respect our team members’ judgements and encourage them to bring new people into the fold – and we really like talking to new people!

The emphasis is really on building relationships, as opposed to checking off a list of desired skills. Organic connection is, therefore, an enormous help in determining whether a candidate will be a good fit at Phase2, whether the connection derives from an awesome conversation, internal introduction, or past collaboration with contractors. We initially look to have an open dialogue in order to gage attitude, passion, and motivations – it is these intangibles that really get us interested in a candidate. A recommendation from one of our employees speaks volumes in this respect.

The Interview Process: exploring skill & creativity

An interview is obviously an evaluation of a candidate, but it should be less a trial than an open discussion. As I mentioned earlier, it’s important to pay attention to the undefinable character traits that will help the candidate succeed at your company. At Phase2, this means being aligned with our six values: dedicated, collaborative, smart, adaptive, authentic, and fun. Even the best developer in the country might not be the right choice if he or she is not a cultural match.

To judge technical abilities, we take code contributions and technology tests into consideration, but another big portion is evaluating thought process and decision-making skills. We ask candidates to talk us through how they would go about tackling certain challenges, getting to the heart of their understanding of the technology and proper processes. This method also offers the advantage of revealing people’s true creativity. Most technologists have an inner flair for creating, and it is always exciting to figure out where their passion comes from, and the unique ways it plays out when solving technical problems.

offering flexibility

According to a Drupal Association survey, 44% of job seekers emphasize location as an important factor in accepting a new job, specifically not having to relocate. Accommodating these candidates means walking the fine line between attracting top talent and maintaining a healthy, engaged team. Requiring all employees to work from a physical office encourages bonding but may scare off truly talented people that consider working from home to be a deal-breaker. At the same time, managing a remote team presents a myriad of logistical challenges in day-to-day communications, in addition to the difficulties of fostering a close-knit team.

At Phase2, our strategy is to offer ultimate flexibility for our employees. Our four offices in DC, New York City, San Francisco, and Portland give our social butterflies the chance to bask in our rich office culture. At the same time, about 30% of our team work remotely across the country. Day-to-day collaboration is achieved through diligent digital communication, video meetings on Google Hangout, and a water-cooler-like chat system which allows us all to bond at a distance. Maintaining an inclusive organization requires a concerted effort (such as our annual all-company gathering at headquarters) but it is well worth it to offer our employees the flexibility to live and work where they prefer to.

Retaining Talent: Letting your People Blossom

Phase2 has been very successful in retaining talent, and a large part of that is offering employees the chance to work on interesting and important projects. In a poll conducted with the podcast’s attendees, 70% believed that the most important factor in keeping staff happy and engaged was interesting work – much higher than compensation (10%), or even culture (20%).

Beyond interesting work, we at Phase2 believe career development is crucial to letting our people blossom. Encouraging long-term growth is key to ensuring your team feels appreciated and valued – it is basically an indication that your company is invested in their future. We manage this by instituting weekly check-ins with managers to discuss progress and goals. In addition, we’ve established well-mapped career trajectories. We feel that it is important to provide concrete steps for individuals to move forward in their own careers, pursuing specialties they themselves have shown an interest in.

How does your team find, hire, and retain top talent? We’d love to hear your thoughts in the comments!

Categories: Elsewhere

Drupal Easy: DrupalEasy Podcast 143: Scheming (Schema.org integration in D8 - Stéphane Corlosquet)

Planet Drupal - Wed, 28/01/2015 - 21:16
Download Podcast 143

Stéphane Corlosquet, Sachni Herath, Kevin Oleary, and Kay VanValkenberg join Mike, Ted, and Ryan for a look into Drupal 8's impressive integration with Schema.org. The RDF UI module is really the star of the show, it promises to provide a super-easy way to create a content type based on an existing schema. We also talk about Dries' 2014 Drupal retrospective, Twig syntax vs. tokens, and Mike's bad internet connection causes hijinx. Picks of the week include a font for demos, a lightweight alternative to a popular Drupal module, and Views changes in D8.

read more

Categories: Elsewhere

Drupal Association News: Drupal Association Board Meeting: 21 January 2015

Planet Drupal - Wed, 28/01/2015 - 21:02

In the first board meeting of 2015, we hit the pause button and looked back on 2014. With all the numbers in and so many projects completed, we wanted to evaluate our success (and our misses) with the board and with you. We feel really good about what we accomplished with the rest of the community. To me, it's doubly impressive because the Association spent so much of last year growing like crazy. We started the year with just about 13 staff and ended the year with 27. We're still small, but doubling your staff is never an easy endeavor. So to go through that kind of change, and to also get some much other good stuff done seems pretty remarkable to me. As always, you can check out the notes, the materials, and the recording, or peruse my summary of the meeting here.


Operational update


I think I can safely say that the theme of 2014 was “Let’s see what we learn from this!” We started the year with a Leadership Plan that outlined some important goals and strategies. We also defined key metrics we would track to help us understand if we were making progress on those goals. This was the first time the organization had this kind of framework to not only get a lot of stuff done, but to understand if that stuff was fulfilling its purpose.

The plan helped us identify lots of things to experiment with, and throughout the year we learned a lot about our plan itself. Metrics didn’t always point to the outcomes we thought they did. Some goals that we set were impossible to meet because of outside influences. But having the plan - that was important. It forced us to think about our work before, during, and after every project. So where did all our experiments take us? A lot of places. Here is a short, incomplete, and grossly over-simplified list of what we accomplished in 2014:

  • We set the proper frame. We developed a vision statement, revamped the mission statement, and created a values statement for the Association.
  • We rebranded, developing new logos for the Association and our programs that reflect our maturity as an organization.
  • We diversified our revenue, by a lot. Introducing new programs and services we were able to make a dent in the ration of Con related revenue to non-Con revenue. This is important for the financial health of the Association, but also because if Cons are our primary source of revenue, we can’t innovate and evolve them with as much courage for fear of undermining our total revenue.
  • Speaking of DrupalCons, we held two really big ones. Lots of things went right - they are well run, with great speakers and great community. We also collected a lot of data about the Cons and identified lots of places to work on for 2015 and beyond. (We promise we heard you about the food in Amsterdam!)
  • The marketing team is creating lots of technical marketing and other branded content that is starting to get great traction in the field. Resources like “Managing Media in Drupal” allow us to showcase the best that Drupal has to offer, regardless of version.
  • The launch of Drupal Jobs was a big milestone for us. We had not launched a product before, and were thrilled to get something out there that the community has repeatedly asked for. It’s still new, and we’re still learning, but we are overall very excited about the steady growth that we have seen.
  • Testbots is an area I have heard about on a weekly basis since I started at the Association. In 2014 we were able to forge a great partnership with the testbed volunteers. The Association is now managing the ongoing operation of the existing testbed infrastructure while the volunteers get to work on the next generation. We’ve seen massive improvements in performance as a result - wait times have dropped from almost 120 minutes to about 20 minutes on average. During the recent Global Sprint Weekend, we went from our usual 4 AWS instances to 20!
  • Drupal.org profiles have also seen a tremendous change in 2014. Again, thanks to the work of some amazing volunteers, we were able to introduce small targeted changes frequently, beginning with profile pictures. The work is not done and there are more changes to come, but profiles are becoming better and better online resumes and community connectors for the community.
  • We managed to be our projected deficit spend for the year. This sets us up well for 2015

I would like to point out that I am extremely proud of the Association staff who endured a lot of growing pains while churning out really good, quality work. In addition to being awesome at what they do, they are hilarious and smart. I owe the a huge debt of gratitude. HOWEVER, all of the bullet points above represent a significant contribution from the volunteers in the community as well. We don’t do our work alone, and we are so grateful to the hundreds of you who have prototyped, tested, coded, documented, trained, mentored, and made puns. Your leadership in the community is noticed and appreciated. Our greatest hope is that we are making your Drupal life a little better.

Marketing Team 2015 Update

The marketing team built a very solid base in 2014 and is prepared to declare 2015 the year of content. Here are a few key initiatives that you can expect this year:

  • More branded content, better presentation. We’re going to turn Drupal.org into the best site out there to discover all you can do with Drupal. We’re currently developing a content strategy that will help us discover all the great content that already exists, but gets lost in the one million+ nodes on the site. Then we can combine that with the great technical content we are also crafting to create more resource centers covering everything from media to search in Drupal.
  • A Drupal.org blog. We are in the middle of a content strategy process led by staff with the Content Working Group and Forum One Communications. It’s clear that we need a better channel to expose the folks who want Drupal news, but who aren’t ready to drink from the firehose that is Drupal Planet. The blog will allow us to reach those folks, and we hope we can use it to highlight the best writing about Drupal that is already being produced.
  • Drupal newsletter. In 2008, we stopped sending a regular Drupal newsletter to the tens of thousands of subscribers on Drupal.org. We’re bringing that back in 2015, with a model similar to that of the blog - the best community content. This newsletter will differ from the Association newsletter in that all the content will be focused on Drupal itself.
  • A challenge will be localization - translating content for our global audience. With the release of Drupal 8 nearing, and its emphasis on localization, we want to meet this need. We’ll be working on strategies to make translation happen on key content.

Of course, there is more to the update than this summary, so I encourage you to check out the presentation.

And then we ran out of time

We were also scheduled to vote on a slate of candidates for the newly formed Licensing Working Group. Unfortunately, we ran out of time. The Executive Committee of the board will be discussing next week to see if we can vote electronically on this topic.

Thanks for a great 2014. Here’s to an even better 2015

Again, thank you for the support, the work, the encouragement, the ideas, and even the complaints. All of it makes us better as an organization, and we hope that when we’re better, Drupal is better. 


 

Flickr Photo: DianaConnolly101

Categories: Elsewhere

Shomeya: 7 Things for Troubleshooting Drupal 7 Theming

Planet Drupal - Wed, 28/01/2015 - 20:05

When I worked in Reality TV Post Production I always had a troubleshooting guide. Most of the time I was working the night shift, and trust me no matter how many times you've done something sometimes your brain just breaks at 2am.

In case you haven't done this before a troubleshooting guide is basically just a list of the steps you take when things break, it helps you avoid that moment of exasperation 3 hours later when you realize how simple the solution really was.

Read more
Categories: Elsewhere

Andrea Veri: The GNOME Infrastructure Apprentice Program

Planet Debian - Wed, 28/01/2015 - 17:59

Many times it happened seeing someone joining the #sysadmin IRC channel requesting participation to the team after having spent around 5 minutes trying to explain what the skills and the knowledge were and why this person felt it was the right figure for the position. And it was always very disappointing for me having to reject all these requests as we just didn’t have the infrastructure in place to let new people join the rest of the team with limited privileges.

With the introduction of FreeIPA, more fine-grained ACLs (and hiera-eyaml-gpg for securing tokens, secrets, passwords out of Puppet itself) we are so glad to announce the launch of the “GNOME Infrastructure Apprentice Program” (from now till the end of the post just “Program”). If you are familiar with the Fedora Infrastructure and how it works you might know what this is about already. If you don’t please read further ahead.

The Program will allow apprentices to join the Sysadmin Team with a limited set of privileges which mainly consist in being able to access the Puppet repository and all the stored configuration files that run the machines powering the GNOME Infrastructure every day. Once approved to the Program apprentices will be able to submit patches for review to the team and finally see their work merged on the production environment if the proposed changes matched the expectations and addressed comments.

While the Program is open to everyone to join, we have some prerequisites in place. The interested person should be:

  1. Part of an existing FOSS community
  2. Familiar with how a FOSS Project works behind the scenes
  3. Familiar with popular tools like Puppet, Git
  4. Familiar with RHEL as the OS of choice
  5. Familiar with popular Sysadmin tools, softwares and procedures
  6. Eager to learn new things, make constructive discussions with a team, provide feedback and new ideas

If you feel like having all the needed prerequisites and would be willing to join follow these steps:

  1. Subscribe to the gnome-infrastructure and infrastructure-announce mailing lists
  2. Join the #sysadmin IRC channel on irc.gnome.org
  3. Send a presentation e-mail to the gnome-infrastructure mailing list stating who you are, what your past experiences and plans are as an Apprentice
  4. Once the presentation has been sent an existing Sysadmin Team member will evaluate your application and follow-up with you introducing you to the Program

More information about the Program is available here.

Categories: Elsewhere

CivicActions: Dockerizing Drupal for Project Development and Testing

Planet Drupal - Wed, 28/01/2015 - 17: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.

Topics
Categories: Elsewhere

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

Planet Drupal - Wed, 28/01/2015 - 16: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: Elsewhere

Dirk Eddelbuettel: RInside 0.2.12

Planet Debian - Wed, 28/01/2015 - 15: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: Elsewhere

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

Planet Drupal - Wed, 28/01/2015 - 15: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: Elsewhere

Russell Coker: SE Linux Play Machine Over Tor

Planet Debian - Wed, 28/01/2015 - 08: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 192.168.0.2:22
HiddenServicePort 80 192.168.0.2:22

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: Elsewhere

ThinkShout: Reimagined Sprints and Introducing RedHen Raiser

Planet Drupal - Wed, 28/01/2015 - 01: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: Elsewhere

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

Planet Debian - Wed, 28/01/2015 - 00: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: Elsewhere

Laura Arjona: Upgrading my computers to Debian Jessie

Planet Debian - Tue, 27/01/2015 - 23: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

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

Pages

Subscribe to jfhovinne aggregator - Elsewhere