emmajane

Depending on the size of your project, you probably have a variation on one of following types of review processes (or maybe a combination of several).

1. Peer Review. We are all equals and equally able to review code and accept it to the project. We learn from one-another and do our best work when we know our peers will be judging it later.
2. Automated Gatekeeper. Our code has test coverage. We trust our tests and only submit work we know will pass a comprehensive test suite. Typically we ask for a second opinion before the code is pushed into the test suite (for automated deployment).
3. Consensus Shepherd. Our community of coders is vigilent, and opinionated. We require consensus from interested parties before code can be marked as "reviewed by the community". We may also have a testbot which is part of our community, making it easier for human coders to know when a suggested change meets minimum standards.
4. Benevolent Dictator. My code, my way. You are welcome to submit your suggestion

emmajane

Teams of One

Solo projects, or projects where you are the sole developer. You are using version control to track your own changes, and perhaps are looking to expand your team and want to implement some structure now so that it's easier to work with others. It is assumed that no one else is working on your published repository, and that you don't need to worry about rebasing your work after it's been published.

Best practices

1. Commit messages are descriptive, and never repeated. If you are working on a problem which has a few follow-up commits to fix minor issues, squash these minor changes into a single commit using git rebase -i.
2. You tag releases according to when code was published, or shared with a client so that you may easily review highlights using git tag -a "tagname" -m "reason for tag".
3. If you are extending another probject, keep your own changes in a separate branch so that you can easily pull changes from the main project into your own work using git branch <branchname>.
4. Yo

emmajane

title	slug
Sources	sources

By default, Sculpin assumes that there will be a source/ directory in your project root containing all of the content for your site.

If you are working from a project template, such as the Getting Started guide describes, your project will already have a source directory. If you are starting your project from scratch, you will need to create a source directory for the content of your site. The source directory should be placed in the root, or top level, directory for your project.

emmajane

[2014-02-25T21:48:44+00:00] INFO: *** Chef 10.30.2 ***

:snip:

[2014-02-25T21:53:28+00:00] INFO: package[php5-curl] upgraded from uninstalled to 5.4.9-4ubuntu2.4
[2014-02-25T21:55:52+00:00] INFO: Discovering pear channel php_pear_channel[pear.drush.org]
[2014-02-25T21:55:57+00:00] INFO: execute[pear channel-discover pear.drush.org] ran successfully
[2014-02-25T21:56:09+00:00] INFO: Installing php_pear[drush] version 6.2.0.0
[2014-02-25T21:57:17+00:00] INFO: template[/etc/php5/conf.d/drush.ini] updated content
[2014-02-25T21:57:17+00:00] INFO: template[/etc/php5/conf.d/drush.ini] owner changed to 0

emmajane

---
layout: default
title: Learner Activities
use:
    - activities

---
<h2>Learner Activities</h2>

<ul>

emmajane

Using Chef 10.12.0 as this is the default package in Ubuntu.

[2014-02-17T10:30:52+00:00] INFO: *** Chef 10.12.0 ***
....
[2014-02-17T10:44:17+00:00] INFO: Discovering pear channel php_pear_channel[pear.drush.org]
[2014-02-17T10:44:22+00:00] INFO: execute[pear channel-discover pear.drush.org] ran successfully
[2014-02-17T10:44:34+00:00] ERROR: php_pear[drush] (drush::pear line 42) has had an error
[2014-02-17T10:44:34+00:00] ERROR: php_pear[drush] (/tmp/vagrant-chef-1/chef-solo-1/cookbooks/drush/recipes/pear.rb:42:in `from_file') had an error:
php_pear[drush] (drush::pear line 42) had an error: RuntimeError: Package drush not found in either PEAR or PECL.
/tmp/vagrant-chef-1/chef-solo-1/cookbooks/php/providers/pear.rb:274:in `pecl?'

emmajane

Transcript of: https://www.youtube.com/watch?v=X71cvxfALaw

Aral Balkan is an experience designer who is working to change the world bringing design thinking to open source, bringing a new category of technology Experience Driven Open Source. Let's hear it for Aral Balkan.

[Digital Feudalism & How to Avoid It. A tale of indie data.]

Thank you. Thank you very much.

Today, we stand at a cross roads. In front of us are two paths. One leads to a digital free land of people who own their own data, devices, and their services. Empowered by this they are able to safe guard their privacy, their civil liberties, and their human rights. The other leads to a digital feudalism, populated by digital serfs. They don't have the option of owning their data, devices, and services. All they can do is rent them from their faceless, corporate landlords. And enfeebled by this they enjoy neither privacy nor civil liberties, nor human rights.