jbgo

UPDATE: A better way! (August 2015)

As pointed out by @johntyree in the comments, using git reflog is easier and more reliable. Thanks for the suggestion!

 $ git reflog
1ed7510 HEAD@{1}: checkout: moving from develop to 1ed7510
3970d09 HEAD@{2}: checkout: moving from b-fix-build to develop
1ed7510 HEAD@{3}: commit: got everything working the way I want
70b3696 HEAD@{4}: commit: upgrade rails, do some refactoring

lucasdinonolte

<?php

/**
 * ModelDecorator Class
 * Decorate Models to seperate out common logic
 * 
 * @author  Lucas Nolte <hello@lucas-nolte.com>
 */

class Modeldecorator {

javiersantos

/*
* Get the current URL of the selected Chrome tab. Call to getCurrent
* By Javier Santos
* https://gist.github.com/javiersantos/c3e9ae2adba72e898f99
*/

var currentURL;

chrome.tabs.query({'active': true, 'windowId': chrome.windows.WINDOW_ID_CURRENT}, 
function(tabs){

greabock

#Как упороться по модульной структуре и областям ответственности в Laravel. А потом стать счастливым.

[UPD] после пары вопросов в личку, решил добавить дисклеймер: Я не считаю, что это единственно верный путь. Я просто говорю вам о том, что существует такой подход.

Когда меня спрашивают для чего нужны сервис-провайдеры в Laravel, я пожимаю плечами и говорю: если вы не знаете зачем они нужны, значит они вам не нужны. Если вы пишите и строите код так, как это описано во всех мануалах, скорее всего вам хватит одного провайдера на всё приложение, и он уже есть сразу. И не надо парить мозг себе и людям. Просто забейте на это все.

Дефолтная структура приложения на laravel выглядит вот так: У вас есть папка Http в которой лежат посредники(раньше это были фильтры) и контроллеры. Так же есть команды, хэндлеры, исключения, модели (последние Тейлор бессовестно бросил просто так - прямо в корне app )... возможно вы сами создаете папки репозиториев, обсерверов... или что-то там еще... потом вы начинаете строить

shankao

<?php
// Levenshtein distance with multibyte support
// Improved from https://gist.github.com/santhoshtr/1710925
function mb_levenshtein($str1, $str2, $encoding = 'UTF-8', $return_lengths = false){
        $length1 = mb_strlen($str1, $encoding);
        $length2 = mb_strlen($str2, $encoding);
        if( $str1 === $str2) {
                if ($return_lengths) {
                        return array(0, $length1, $length2);
                } else {

alces

• using Ansible command line:

ansible-playbook --connection=local 127.0.0.1 playbook.yml

• using inventory:

127.0.0.1 ansible_connection=local

glenhallworthreadify

const puppeteer = require('puppeteer');

class Webpage {
    static async generatePDF(url) {
        const browser = await puppeteer.launch({ headless: true }); // Puppeteer can only generate pdf in headless mode.
        const page = await browser.newPage();
        await page.goto(url, { waitUntil: 'networkidle', networkIdleTimeout: 5000 }); // Adjust network idle as required. 
        const pdfConfig = {
            path: 'url.pdf', // Saves pdf to disk. 
            format: 'A4',

christopheranderton

/* == Montserrat Font Family Styles == */


/* @group Montserrat
-------------------------------------------------------------- */

/* = Weights Montserrat  
-------------------------------------------------------------- */

.thin {

dunglas

<?php

$query = <<<'GRAPHQL'
query GetUser($user: String!) {
   user (login: $user) {
    name
    email
    repositoriesContributedTo {
      totalCount
    }

afloesch

Jenkins in Docker (docker-in-docker)

Testing Jenkins flows on your local machine, or running Jenkins in production in a docker container can be a little tricky with a docker-in-docker scenario. You could install Jenkins to avoid any docker-in-docker issues, but then you have Jenkins on your machine, and the local environment is likely going to be a fairly different from the actual production build servers, which can lead to annoying and time-consuming issues to debug.

Build environment differences are precisely why there is a strong argument to be made to run build processes strictly in docker containers. If we follow the philosophy that every build step or action should run in a docker container, even the Jenkins server itself, then we get massive benefits from things like, total control over the build environment, easily modify the build environment without the possibility of adversely effecting other jobs, explicit and strongly controlled tool versions,