Feed aggregator

Midwestern Mac, LLC: Thoughts on the Acquia Certified Drupal Site Builder Exam

Planet Drupal - Wed, 13/05/2015 - 07:16

After taking the trifecta of Acquia Developer Certification (General, Back-end, Front-end) exams and earned a new black 'Grand Master' sticker, I decided to complete the gauntlet and take the Acquia Certified Drupal Site Builder Exam at DrupalCon LA.

Categories: Elsewhere

Zlatan Todorić: How to answer as a master

Planet Debian - Wed, 13/05/2015 - 02:17

I have spent some fair amount of time during the life to explore making great responses to generic question (technical one included) and I can say without doubt that it is a pretty simple thing one could learn. First of all, answering question via email or in personal, it is very important that people feel that the person answering is there and is really "getting" their question. So a personal notice at beginning or at the end is not necessary but is a big plus. Particular part of answer should have 3 phases: straight yes or no answer, brief explaining why yes or no, and then explaining the opposite solution. Very important to keep it precise and simple as possible while explaining all what is needed for the person which asked question.

For example Joe asks:

Can I install library libfoo1.2 without breaking software foo1.1

And Jane would answer:

Hi Joe,

very good question as people often do try things like that and could end up in complicated situation.

So the answer is NO.

Pulling the libfoo1.2 would break foo1.1 because there were numerous changes from libfoo1.1 that break backward compatibility and there was also rewriting and porting to a newer version of language.

Now having that out of way, you can safely pull also foo1.2 and install it with libfoo1.2 which is tested and should work for you without any problems.

Best regards,


And that's it. Lean, clean, cyborg.

Categories: Elsewhere

ThinkDrop Consulting: Continuous Deployment, Integration, Testing & Delivery with Open DevShop

Planet Drupal - Wed, 13/05/2015 - 01:34

Well before "DevOps" was a thing, and long before DevShop existed, was "CI". Continuous Integration is a critical part of successful software development.  As a web CMS, Drupal has lagged a bit behind in joining up with this world of CI.

One of the reasons that we don't see CI being used as much as we'd like is that it is hard to setup, and even harder to maintain long term.  Wiring up your version control systems to your servers and running tests on a continual basis takes some serious knowledge and experience. There are a lot of tools to try and make it easier, like Jenkins, but there is still a lot of setup and jerry-rigging needed to make everything flow smoothly from git push to test runs to QA analysis and acceptance.

Setup is one thing, keeping things running smoothly is another entirely. With a home-spun continuous integration system, the system operators are usually the only ones who know how it works. This can become a real challenge as people move to new jobs or have other responsibilities.

This is one of the reasons why we created DevShop: to make it ridiculously easy to setup and keep up a CI environment. DevShop's mission is to have everything you need out of the box, with as little setup, or at least as simple a setup process as possible.

Continuous Deployment

DevShop has always had Continuous Deployment: When a developer pushes code to the version control repository, it is deployed to any environment configured to follow that branch.  This is usually done on the main development branch, typically called master, and the environment is typically been called dev.

However for the last few years, DevShop has had the ability to host unlimited "branch environments".  This means that individual developers can work on their code on separate branches, and each one can get it's own copy of the site up and running on that branch.  This reduces the chances for conflicts between multiple developers and helps reduce the time needed to debug problems in the code because if you find a problem, you know what branch it came from.  

We've found that having branch environments is a much more productive way to code than a shared dev environment on the master branch.

Pull Request Environments

DevShop has been able to react to GitHub Pull Requests by creating a new environment since last year.  Each project can be configured to either clone an environment or run a fresh install every time a Pull Request is created. It will even tear down the environment when the Pull Request is closed.

Developers have less management to do using Pull Request environments: They don't need access to DevShop at all.  Everything is fully automated.

This method is even better than setting up branch environments, since Pull Requests are more than just code: anyone on the team can comment on every Pull Request, offering advice or asking questions about the proposed code.  Users can even comment on individual lines of code, making the peer review process smoother than ever by letting teams communicate directly on the code..

Continuous Testing

Recently we've added built-in behat testing to DevShop: When a "Test" task is triggered, the logs are saved to the server and displayed to users through the web interface in real time.   The pass or fail result is then displayed in the environment user interface as green or red, respectively, along with the full test results with each step highlighted with Pass, Fail, or Skipped.

This gives developers instant feedback on the state of their code, and, because it is running in an online environment, others can review the site and the test results along with them.  

The future of DevShop testing is to incorporate even more tests, like PHPUnit, CodeSniffer, and PHP Mess Detectors.  Having a common interface for all of these tests will help teams detect problems early and efficiently.

Continuous Integration

Continuous Integration can mean different things to different people.  In this context I am referring to the full integration of version control, environments, tests, and notifications to users.  By tying all of these things together, you can close the feedback look and accelerate software development dramatically.

GitHub, the most popular git host in the world, got to be that way in part by providing an extremely robust API that can be used to setup continuous integration systems. Each repository can have "Post commit receive" webhooks setup that will notify various systems that new code is available.

The "Deployments" API" allows your systems to notify github (and other systems) that code was deployed to certain environments.  The "Commit Status" API can be used to flag individual commits with a Pass, Fail, or Pending status.  This shows up in the web interface as a a green check, a red X, or an orange circle both on the commit and on each open Pull Request in the repository.  A failing commit will notify developers that they should "Merge with Caution", making it much less likely that code reviewers will merge bad code.

DevShop now leverages both the Deployments and the Commit status APIs for Pull Request environments.

Deployments are listed right in line with the commit logs of a pull request, and give the team direct links to the environments created by devshop.

Commit Statuses display not only a pass or fail status, but also link directy to test results, giving developers the instant feedback needed to respond quickly to issues.

Continuous Notification

An important part of any CI system is the notifications.  Without them, developers and their teams don't know that there is anything for them to do. GitHub has great integration with just about any chat service, and now so does DevShop.  

When your CI system is integrated with a chat service, the entire team gets visibility into the progress and status of the project.  New commits pushed notify others that there is new work to pull, and test notifications alert everyone to the passing or failing of those code pushes. Having immediate feedback on these types of things in crucial for maintaining a speedy development pace.

Continuous Delivery

With all of the pieces in place, you can start to think about Continuous Delivery.  Continuous Delivery is the act of "going live" with your code on a continuous basis, or at least very often.

DevShop allows your live environment to track a branch or a tag.  If tracking a tag, you must manually go in and deploy a new tag when you are ready to release your code.

If tracking a branch, however, your code will deploy as soon as it is pushed to that branch.  Deploy hooks ensure all of the appropriate things run after the code drop, such as update.php and cache clearing.  This is what makes continuous delivery possible.

If using Pull Requests for development, you can use GitHub's Merge button to deploy to live if you setup your production environment to track your main branch.  With the Commit Status and Deployment APIs, you can be sure that not only did the tests pass but the site looks good with the new code.

Merging to deploy to live is a great way to work.  You no longer need to access devshop to deploy a new tagged release, and you no longer need to manually merge code, hoping that everything works.

If it's green, it's working.  If your tests are robust enough, you can guarantee that the new code works.

If your tests are so complete that you start to reach 100% code coverage, you can start thinking about true continuous delivery: Tests Pass? Automatically merge to live and deploy.  This requires that your tests are amazing and reliable, but it is possible.

DevShop doesn't have the ability out of the box to setup true continuous delivery, but it would not take too much work.  You could use the hosting task status hook to fire off a merge using GitHub's API.

As more people start to use Continuous Delivery, we can work on incorporating that into the devshop process.

All wrapped up in a Bow

With DevShop, you will spend (much) less time on your support systems so you can focus on your websites.  We hope to continue to find ways to improve the development process and incorporate them directly into the platform.

We encourage everyone to embrace continuous integration principles on their projects, whether it is using DevShop or not.  Not only does efficiency go up, but code quality and morale does too.  

If you are a software developer, having tests in place will change your life. Everyone involved in the project, from clients to quality assurance folks to the dev team, will sleep better at night.

Tags: devshopcontinuous integrationPlanet Drupal
Categories: Elsewhere

Drupal core announcements: Drupal 8 beta 11 on Wednesday, May 27, 2015

Planet Drupal - Wed, 13/05/2015 - 00:56

The next beta release for Drupal 8 will be beta 11! (Read more about beta releases.) The beta is scheduled for Wednesday, May 27, 2015.

To ensure a reliable release window for the beta, there will be a Drupal 8 commit freeze from 00:00 to 23:30 UTC on May 27.

Categories: Elsewhere

Steinar H. Gunderson: In all fairness

Planet Debian - Tue, 12/05/2015 - 21:30

Since I had a long rant about Lenovo customer service a while back:

My laptop died again during travels; at first, it was really unstable (whenever I'd hold it slightly wrong, it would instantly crash), then later, it would plain refuse to boot (not even anything on the display).

So I called Lenovo, and after some navigating of phone menus I got to someone who took my details, checked my warranty (“let's see, you have warranty until 2018”—no months of arguing this time!) opened a case and sent me on to tech support. Tech support said most likely, the motherboard was broken, and that a technician would call me; today, the tech called, and arrived at work to swap my motherboard. 30 minutes on the phone, 20 minutes waiting for the technician to switch the motherboard (I would probably have used more than an hour myself). And voila, working laptop. (Hope it's stable from now on.)

My only gripe is that I forgot to remind him after the repair to give me new rubber feet—he'd already said it wouldn't be a problem, but we both forgot about it. But overall, this is exactly how it should be—quite unlike last time.

Categories: Elsewhere

Amazee Labs: DrupalCon Los Angeles - Day 1: Dawn of the Drupalistas

Planet Drupal - Tue, 12/05/2015 - 20:15
DrupalCon Los Angeles - Day 1: Dawn of the Drupalistas

Yesterday, just shortly after the sun sprung up and sparked southern California’s beautiful coastal lines, the doors of LA’s Convention Center opened. Welcoming with it, a first wave of eager Drupalistas and surrounding them by its air conditioned walls. And for the subsequent days that are surely to follow, it will continue to receive and house those, transforming it, to the home of DrupalCon 2015.

To some of us, this day began just like two previous iterations in the past, with the Drupal 8 Training for Drupalistas. And like the preceding ones before, the turn out was again, lovely. A fresh batch of new ambitious students took their seats and embarked on a cinematic journey, led by our resident training director, Diana Montalion.

From lively exchanges of know-how, to focused, almost silent moments, the classroom experienced a day of captivating performances. And in-between those, pupils were given hourly breaks to take a breath and pick from a variety of delicious beverages (there were cookies!) and the oh so essential, mandatory coffee.

After a wholesome feast around noon-ish, the reins were passed on to Jason, who expertly guided the keen students through the inner workings of Drupal 8’s translation system. Shortly thereafter, Kathryn took over to introduce them to the beautiful side of Drupal 8 (theming!) before finally ending again within Diana’s experienced hands.

Meanwhile, the lower floor saw a much more handy development: the exhibition hall of large, empty at first, but slowly building up to a small but respectable miniature city of brands. Replacing muffled sounds of classroom keyboards with the repeating cracks of rising booths, only to be broken apart by the occasional clash of shouty staff members.

Thus the day drew to an end, and our students were being led on their way, charged with knowledge and filled with cookies. The building emptied its walls again to prepare for tomorrow, when at dawn, the drupalistas will rise again.

Categories: Elsewhere

Jim Birch: Dude, Where are my Templates? Using the Drupal 7 Theme Developer to find the way.

Planet Drupal - Tue, 12/05/2015 - 19:11

The first line of the description of the Drupal Theme Developer Module says that it is "Firebug for Drupal themeing".  I couldn't agree more.  This is the ultimate tool when you need to find out which theme hook, or which template file to modify based on your design and layout needs.

It is a finicky module though, it doesn't work with the latest version of one of it's dependencies, simplehtmldom API, and when turned on it can break your layout. 

Note that this module injects markers into the DOM to do its magic. This may cause some themes to behave erratically and less capable browsers may make it worse (especially IE)/. Enable it when needed, and disable it afterwards.

To ensure I install the correct branch of the modules, and to speed up enabling and disabling, I set up some aliases in my local/development computer's .bash_profile:

Read more

Categories: Elsewhere

Nikro: Moldcamp 2015 - Session Submissions!

Planet Drupal - Tue, 12/05/2015 - 15:56

If you haven't heard yet, we've announced earlier that Moldcamp 2015 is on it's way! Second edition of the Drupal Camp hosted by a small country in the Eastern Europe - Moldova.

Categories: Elsewhere

Simon Josefsson: Certificates for XMPP/Jabber

Planet Debian - Tue, 12/05/2015 - 15:43

I am revamping my XMPP server and I’ve written down notes on how to set up certificates to enable TLS.

I will run Debian Jessie with JabberD 2.x, using the recent jabberd2 jessie-backport. The choice of server software is not significant for the rest of this post.

Running XMPP over TLS is a good idea. So I need a X.509 PKI for this purpose. I don’t want to use a third-party Certificate Authority, since that gives them the ability to man-in-the-middle my XMPP connection. Therefor I want to create my own CA. I prefer tightly scoped (per-purpose or per-application) CAs, so I will set up a CA purely to issue certificates for my XMPP server.

The current XMPP specification, RFC 6120, includes a long section 13.7 that discuss requirements on Certificates.

One complication is the requirement to include an AIA for OCSP/CRLs — fortunately, it is not a strict “MUST” requirement but a weaker “SHOULD”. I note that checking revocation using OCSP and CRL is a “MUST” requirement for certificate validation — some specification language impedence mismatch at work there.

The specification demand that the CA certificate MUST have a keyUsage extension with the digitalSignature bit set. This feels odd to me, and I’m wondering if keyCertSign was intended instead. Nothing in the XMPP document, nor in any PKIX document as far as I am aware of, will verify that the digitalSignature bit is asserted in a CA certificate. Below I will assert both bits, since a CA needs the keyCertSign bit and the digitalSignature bit seems unnecessary but mostly harmless.

My XMPP/Jabber server will be “chat.sjd.se” and my JID will be “simon@josefsson.org”. This means the server certificate need to include references to both these domains. The relevant DNS records for the “josefsson.org” zone is as follows, see section 3.2.1 of RFC 6120 for more background.

_xmpp-client._tcp.josefsson.org. IN SRV 5 0 5222 chat.sjd.se. _xmpp-server._tcp.josefsson.org. IN SRV 5 0 5269 chat.sjd.se.

The DNS records or the “sjd.se” zone is as follows:

chat.sjd.se. IN A ... chat.sjd.se. IN AAAA ...

The following commands will generate the private key and certificate for the CA. In a production environment, you would keep the CA private key in a protected offline environment. I’m asserting a expiration date ~30 years in the future. While I dislike arbitrary limits, I believe this will be many times longer than the anticipated lifelength of this setup.

openssl genrsa -out josefsson-org-xmpp-ca-key.pem 3744 cat > josefsson-org-xmpp-ca-crt.conf << EOF [ req ] x509_extensions = v3_ca distinguished_name = req_distinguished_name prompt = no [ req_distinguished_name ] CN=XMPP CA for josefsson.org [ v3_ca ] subjectKeyIdentifier=hash basicConstraints = CA:true keyUsage=critical, digitalSignature, keyCertSign EOF openssl req -x509 -set_serial 1 -new -days 11147 -sha256 -config josefsson-org-xmpp-ca-crt.conf -key josefsson-org-xmpp-ca-key.pem -out josefsson-org-xmpp-ca-crt.pem

Let’s generate the private key and server certificate for the XMPP server. The wiki page on XMPP certificates is outdated wrt PKIX extensions. I will embed a SRV-ID field, as discussed in RFC 6120 section and RFC 4985. I chose to skip the XmppAddr identifier type, even though the specification is somewhat unclear about it: section says that it “is no longer encouraged in certificates issued by certification authorities” while section says “Use of the ‘id-on-xmppAddr’ format is RECOMMENDED in the generation of certificates”. The latter quote should probably have been qualified to say “client certificates” rather than “certificates”, since the latter can refer to both client and server certificates.

Note the use of a default expiration time of one month: I believe in frequent renewal of entity certificates, rather than use of revocation mechanisms.

openssl genrsa -out josefsson-org-xmpp-server-key.pem 3744 cat > josefsson-org-xmpp-server-csr.conf << EOF [ req ] distinguished_name = req_distinguished_name prompt = no [ req_distinguished_name ] CN=XMPP server for josefsson.org EOF openssl req -sha256 -new -config josefsson-org-xmpp-server-csr.conf -key josefsson-org-xmpp-server-key.pem -nodes -out josefsson-org-xmpp-server-csr.pem cat > josefsson-org-xmpp-server-crt.conf << EOF subjectAltName=@san [san] DNS=chat.sjd.se otherName.0=;UTF8:_xmpp-server.josefsson.org otherName.1=;UTF8:_xmpp-client.josefsson.org EOF openssl x509 -sha256 -CA josefsson-org-xmpp-ca-crt.pem -CAkey josefsson-org-xmpp-ca-key.pem -set_serial 2 -req -in josefsson-org-xmpp-server-csr.pem -out josefsson-org-xmpp-server-crt.pem -extfile josefsson-org-xmpp-server-crt.conf

With this setup, my XMPP server can be tested by the XMPP IM Observatory. You can see the c2s test results and the s2s test results. Of course, there are warnings regarding the trust anchor issue. It complains about a self-signed certificate in the chain. This is permitted but not recommended — however when the trust anchor is not widely known, I find it useful to include it. This allows people to have a mechanism of fetching the trust anchor certificate should they want to. Some weaker cipher suites trigger warnings, which is more of a jabberd2 configuration issue and/or a concern with jabberd2 defaults.

My jabberd2 configuration is simple — in c2s.xml I add a <id> entity with the “require-starttls”, “cachain”, and “pemfile” fields. In s2s.xml, I have the <pemfile>, <resolve-ipv6>, and <require-tls> entities.

Some final words are in order. While this setup will result in use of TLS for XMPP connections (c2s and s2s), other servers are unlikely to find my CA trust anchor, let alone be able to trust it for verifying my server certificate. I’m happy to read about Peter Saint-Andre’s recent SSL/TLS work, and in particular I will follow the POSH effort.

Categories: Elsewhere

Drupalize.Me: Installing and Configuring Dreditor

Planet Drupal - Tue, 12/05/2015 - 15:02

With DrupalCon Los Angeles underway we thought it might be a good time to introduce (or reintroduce) folks to [Dreditor](https://dreditor.org/) (short for "Drupal editor"). Dreditor is a collection of user scripts, which alter browser behavior on specific pages on the drupal.org domain. The features of dreditor are mostly helpful in the issue queue and during the patch review process.

We have a video [Installing and using Dreditor](https://drupalize.me/videos/installing-and-using-dreditor) if you'd like to follow along, but since recording installation of Dreditor is even easier. Let's take a look at the changes, and how we can use this powerful tool to make interacting with the issue queue easier.

Categories: Elsewhere

Cocomore: MySQL - Setup

Planet Drupal - Tue, 12/05/2015 - 14:58

When setting up a MySQL Server there are a lot of things to consider. Most requirements depend on the intended usage of the system.

read more

Categories: Elsewhere

ERPAL: Manage agile projects with structure and control

Planet Drupal - Tue, 12/05/2015 - 12:45

In the previous part of our blog series, we talked about unrealistic budgets and deadlines. Today our focus is on structure and control in agile projects.

In software development, there’s a lot of conjuring and experimentation going on with agile projects, and many homemade definitions for the word "agile" are floating around. But agile only means that one reacts to changing project requirements, and is thus flexible during development, with the result being a software product that really provides value when used.

In large projects that extend over a longer period of time, conditions change; it’s natural. In order to maintain the defined project objectives despite these new conditions, the existing requirements need to be checked. To achieve this, it’s necessary to know what’s already been implemented and what’s still outstanding. Scrum and agile approach do not imply that:

  • there’s no planning in advance,
  • there’s no concept, or that
  • there aren’t any acceptances.

An agile project follows the same rules as I’ve described earlier, but changes are allowed. As always, you have to consider that unplanned things cannot be controlled. Often, the billing procedures are controversial. I’ve already written a post on this topic: Agile work at a fixed price. The very concept of an agile project provides a framework within which to move and control changes. This framework ensures that a path that was possibly set wrong from the start – that won’t lead to the defined target – simply is not taken. If the plan in an agile project doesn’t exist in the form of a concept, the current status of the project can’t be determined and evaluated.


Other blog posts of this series:

6 steps to avoiding unrealistic budgets and deadlines in projects

6 rules to follow to promote communication in projects

3 things to consider when creating project specifications

Agile projects for a fixed price? Yes you can!

Setting objectives in projects with these 3 rules

These 3 questions help you to ensure satisfactory project results

Categories: Elsewhere

Michal &#268;iha&#345;: python-gammu 2.2

Planet Debian - Tue, 12/05/2015 - 12:00

After recent porting python-gammu to Python 3, it was quite obvious to me that new release will have some problems. Fortunately they have proven to be rather cosmetic and no big bugs were found so far.

Anyway it's time to push the minor fixes to the users, so here comes python-gammu 2.2. As you can see, the changes are pretty small, but given that I don't expect much development in the future, it's good to release them early.

Filed under: English Gammu python-gammu SUSE Wammu | 0 comments

Categories: Elsewhere

Deeson: We're hiring: Creative Director

Planet Drupal - Tue, 12/05/2015 - 09:23
Could you be the one to make your mark here at Deeson?

We're looking for a Creative Director. That's a brand new role for us so you'll be the very first CD to grace our offices.

A lot of expectation? Maybe. But the perfect opportunity to lead our team of talented designers and put your stamp on some award-winning work.  

Why now? 

In short, we've increased our portfolio of clients and our designers are in demand. 

It's a perfect time for someone new to come and join our dynamic leadership team, contributing to key decisions as we enter our next phase of growth.

We're at a stage where we feel ready for a strong-minded Creative Director to help develop the team and help shape the direction of the agency.  

Why me?

We're looking for someone talented, that's a given.

But as well as a killer portfolio, we want someone who has an interest in nurturing the skills of those in their team. Development is really important to us at Deeson; we'll be looking for ideas about how you would grow your team's skills and confidence.    You could be a Senior Designer with tonnes of managerial experience looking for your next move or a Creative Director looking for your next challenge. If you fit the criteria we'd love to hear from you.   What else? A great bunch of people to work with and a progressive agency culture.   A huge range of benefits, including flexi working, team lunches and an unlimited training budget.    Oh, and we're located in one of the UK's most beautiful cities too. Check out our full story here.   Read the full job spec and apply here.       


Categories: Elsewhere

Deeson: Site configuration strategy (or how to manage your settings.php files)

Planet Drupal - Tue, 12/05/2015 - 09:10

Managing site configuration across multiple hosting and staging environments can get complicated, and if each one of these requires a settings.php file making sure that you consistently apply configuration can be a nightmare.

This is especially true when you start requiring different files at different points – it's very easy to lose track of which setting is where.

A typical example here at Deeson might be a site that's usually hosted on Acquia's platform, but that we need to be able to work locally on (we use VDD for this).

That probably gives you 3 settings.php files: one for your local, one for the live domain name and one for Acquia's staging URLs. We'll also have different configuration for each of these. An example is where both reroute email and shield need to be disabled only on live, if our site has 3rd party integrations then we'll configure different API keys on staging and caching is always on on live.

So, how do we solve this?

In much the same way that we don't create a site-wide views feature, and instead we use a modular approach – for example one feature for news and another for events, we should do the same with our configuration and split it up. We don't do this by environment, but by module. So all the performance stuff together, all the security stuff together etc.

For example, you might have a reroute email file, that could read something like this:

$conf['reroute_email_address'] = "rerouted_mail@example.com"; $conf['reroute_email_enable_message'] = TRUE; $conf['reroute_email_enable'] = TRUE; if (SETTINGS_LIVE_DOMAIN) { $conf['reroute_email_enable'] = FALSE; }

This is clearer and less error prone than the situation that can occur where you can't instantly tell which setting will apply in a given situation. And by coding your conditions defensively you'll improve security.

So it's possible that you might still have those three settings.php files, but instead of adding config directly to them all they do is define the database settings and then do something like this:

// e.g. dev, stage or prod or read from $_ENV['AH_SITE_ENVIRONMENT'] on Acquia. // Master.inc could read this instead of the “scopes” concept? define('SETTINGS_ENVIRONMENT', 'prod') // e.g. local or acquia define('SETTINGS_HOSTING', 'acquia'); <?php // TRUE only on the actual live domain - so any testing domains, including the "live preview" should give this FALSE. define('SETTINGS_LIVE_DOMAIN', FALSE | TRUE); foreach (glob('sites/all/conf/*.settings.inc') as $file) { require_once $file; }

See that glob call? Create files in a new dir – sites/all/conf – like thing.settings.inc and place your config in there, using 'if' statements to react to the different envrionments.

Glob sorts by file name, so prefix each of these files with a number if you need them to be in a specific order, e.g 00-master.inc, 10-reroute-email.inc.

Here are some suggestions for files you might create (all to end in .settings.inc):

  • drupal-defaults (Maybe copy settings.default.php in here and update it keep it in sync with core updates?)
  • master
  • warden
  • shield
  • reroute_email
  • mandrill
  • performance (caching, aggregation etc. Only force these on live, if you must)
  • your-api-here

In this manner we can create sets of default settings php files which are likely to be common across projects. This makes initial setup to our standards and best practice simple. Any deviation from the standards can then be configured and described in the main settings file for the site.

Categories: Elsewhere

DrupalCon News: Session Submission Live!

Planet Drupal - Tue, 12/05/2015 - 06:21

With the call for papers officially open, we wanted to take a moment to give you all of the details you should know about sessions: what new and cool tracks we are offering, how to submit an awesome session submission, and how session selection works.


Categories: Elsewhere

Bits from Debian: Debian Ruby team sprint 2015

Planet Debian - Tue, 12/05/2015 - 00:00

The Debian Ruby Ruby team had a first sprint in 2014. The experience was very positive, and it was decided to do it again in 2015. Last April, the team once more met at the IRILL offices, in Paris, France.

The participants worked to improve the quality Ruby packages in Debian, including fixing release critical and security bugs, improving metadata and packaging code, and triaging test failures on the Debian Continuous Integration service.

The sprint also served to prepare the team infrastructure for the future Debian 9 release:

  • the gem2deb packaging helper to improve the semi-automated generation of Debian source packages from existing standard-compliant Ruby packages from Rubygems.

  • there was also an effort to prepare the switch to Ruby 2.2, the latest stable release of the Ruby language which was released after the Debian testing suite was already frozen for the Debian 8 release.

Left to right: Christian Hofstaedtler, Tomasz Nitecki, Sebastien Badia and Antonio Terceiro.

A full report with technical details has been posted to the relevant Debian mailing lists.

Categories: Elsewhere

Shomeya: Running Your Agency/Tech Company like a Factory is Destroying Humanity: Part 2

Planet Drupal - Mon, 11/05/2015 - 21:45

In case you missed it Part 1

Very carefully I cut the letters out of the magazines that are strewn across my table. My fingers covered in glue, I lay them out one at a time on a piece of heavy duty paper, a message for the CEO of my friend's company. A message to save humanity:

"Your company is following the startup lemmings off the cliff, do you care?"

-- Anonymous

Every year your agency or startup is throwing away thousands of dollars, because you follow some very bad habits that reward mediocrity and egos. I know because as a CEO of even a tiny company, I've watched you bleed and wanted to hand you the bandage.

At Shomeya I am the CEO and the Project manager, when I fuck up and put my programmer in a bad position I see how it effects his work AND his home life. I feel every late night, and regret every poor choice when I said yes to the client, because I deal with the results.

So I learned to adjust Shomeya to make better choices. And the good news is these choices can scale because they are based on something we all deal with no matter what the size of our payroll; human brains.

Read more
Categories: Elsewhere

Simon Josefsson: Laptop decision fatigue

Planet Debian - Mon, 11/05/2015 - 21:31

I admit defeat. I have made some effort into researching recent laptop models (see first and second post). Last week I asked myself what the biggest problem with my current 4+ year old X201 is. I couldn’t articulate any significant concern. So I have bought another second-hand X201 for semi-permanent use at my second office. At ~225 USD/EUR, including another docking station, it is an amazing value. I considered the X220-X240 but they have a different docking station, and were roughly twice the price — the latter allowed for a Samsung 850 PRO SSD purchase. Thanks everyone for your advice, anyway!

Categories: Elsewhere


Subscribe to jfhovinne aggregator