UPD: Найдено решение без затрат памяти на cDock. Как добавить скрипт в автозагрузку можно почитать тут

#!/bin/bash
defaults write NSGlobalDomain AppleInterfaceStyle Dark
killall Dock
sleep 3
defaults remove NSGlobalDomain AppleInterfaceStyle

-- orig --
Уже обновились до Yosemite? И я обновился. И мне всё нравится кроме одной детали. Кому как конечно, на вкус и цвет все фломастеры разные, но для меня это оказалось весьма критично. Суть в том что док в ёсе стал прозрачным, поскольку я много сижу в редакторах со светлой цветовой схемой (белый бэкграунд) и часто разрабатываю бекофисные веб-интерфейсы с белым фоном, то при переключении приложений док просто сливается и причиняет моим глазам.. в общем глаза через 10 минут ломаются. Есть конечно вариант с включением "dark mode" но в этом случае с доком всё в порядке, зато menu-bar (основное меню) тоже становится черным и начинает ломать глаза уже оно. В итоге желание моё было просто, оставить menu-bar светлым, а док, панель переключения приложений (cmd+tab) и папку с приложениями в доке - сделать тёмными. То есть фактически вернуться к старой схеме тёмный док и светлое меню, к которой я прикипел со времен Snow Leopard. Серфить пришлось где-то два часа, надо сказать что людей с такими же претензиями как моя - я не нашел. Уже начал подумывать об откате, как решение нашлось.

Проект называется cDock и при помощи какой-то своей магии он делает ровно то, что мне нужно. Интерфейс утилитки выглядит так

Тем есть целый набор, можно поэкспериментировать. Обратите внимание на стрелку, она указывает на чекбокс который нужно снять, иначе утилита будет пытаться вернуть цветной сайдбар в файндере, потеряв часть иконок. То есть часть из них будет резать глаз белыми листочками-болванками. Утилитка самопальная, поэтому ничего удивительного в том что она вот так косячит - нет. Для меня необходимой фичей была только цветовая схема дока и с этой задачей утилита справилась на отлично.
После установки утилита вешает какой-то свой демон который автоматом загружается после перезагрузки, то есть что-то там делать руками при каждой перезагрузке не понадобится. Антивирусом я пошуршал - ничего. Откат к родным настройкам - есть (в селекторе выбора темы). Пользоваться на свой страх и риск.
А теперь немного дегтя. За всё нужно платить, в данном случае платить придется вот так



Не слишком приятно, но не так уж дорого, за такую кучу удовольствия, работать в среде с привычным внешним видом. Впрочем решать конечно каждый должен сам.
Настораживает жесткость с которой любимый эпол начинает напаривать интерфейсные решения, но это наверное глуповатая претензия учитывая всю историю.. Остается уповать на сообщество и силу убеждения.. и на таких вот чудесных самоделкиных которые могут выручить в последний момент. Если кто-то знает какими "родными" настройками можно решить описанную проблему - был бы очень признателен за комментарий.

Есть такая приблуда forever, если говорить коротко о её назначении - логирование ошибок и автоматический перезапуск приложения после его падения.
Собственно эта заметка о том как перезапускать приложение при помощи forever, если рядом запущено ещё одно приложение с таким же именем запускающего приложение скрипта. Обычно проще всего убивать по имени, но вот так получилось что имена скриптов у меня перекрылись и перезапуск одного приложения стал вызывать смерть других. Логично, на помощь приходит uid, который позволяет каждому приложению присвоить понятно что, и таким образом решить "проблему" с уникальностью имен скриптов, запущенных одновременно на одной машине.
Пример скрипта для перезапуска приложения по uid

#!/bin/bash
APP_DIR="/home/user/app-folder"
FOREVER="/usr/local/bin/forever"
APP_UID=appUniqUid
DAEMON=$FOREVER" --append --uid $APP_UID start --spinSleepTime 10000 --minUptime 1000 --sourceDir "$APP_DIR
APP_SCRIPT="app.js"

## vars for app env
export APP_PORT=4433
export NODE_ENV=production
####

echo -n "Stopping $APP_SCRIPT: "
$FOREVER stop $APP_UID && echo 'ok, stoped' || echo 'error on stop node app'
echo -n "Starting $APP_SCRIPT: "
$DAEMON $APP_SCRIPT && echo 'ok, started' || echo 'error on start node app'

Теперь в консоли можно выполнить

forever list

и увидеть искомый uid.
Зачем это вообще надо, ведь forever сам должен уметь перезапускать всё и после деплоя и после падения?? Должен, да, но вот бывает такая фигня, когда после деплоя взлетает всё криво, или по каким-то другим причинам приложению требуется насильная перезагрузка. А вспоминать как там рулить forever в таких случаях мне лень. Я лентяй, поэтому я написал этот скриптик.

Суть проблемы: nginx установлен через brew и стандартный интерфейс добавления приложений через Системные настройки -> Защита и безопасность -> Брандмауэр -> Параметры брандмауэра -> "+" его разумеется не видит и добавить через путь не дает (защита от криворукости видимо). Выход - консоль. Пример добавления

# добавляем приложение в список
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /usr/local/Cellar/nginx/1.6.2/bin/nginx
# разрешаем входящие соединения
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /usr/local/Cellar/nginx/1.6.2/bin/nginx
# запрещаем входящие соединения
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --blockapp /usr/local/Cellar/nginx/1.6.2/bin/nginx

Теперь nginx нужно будет перезапустить и всё должно взлететь. REM: замечено что после выхода из спящего режима настройка эта по непонятным причинам работать перестает. То есть приходится удалять правило, останавливать nginx, добавлять правило обратно, запускать nginx. Причины я пока не понял, перезапускаю скриптиком по необходимости.

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

Route::post('/lala-page', ['as' => 'lalala', 'uses' => 'subfolder/LalaController@myfinc']);

То оно мало того что выглядит убого так ещё и не работает. А решение было элементарнейшее: перестроить карту классов композером. То есть просто создаем все свои папки где будут жить контроллеры, раскладываем туда контроллеры

app/controllers
app/controllers/my
app/controllers/admin
...

В самих контроллерах ничего не меняем. Просто перестраиваем автозагрузку (из папки проекта разумеется)

composer dump-autoload

И вуаля, все вложенные контроллеры заработали. Мне бы такие инструменты лет 10 назад.. Ну пять хотя-бы :)
REM: см. git diff vendor/composer/autoload_classmap.php

Есть ли у вас такая проблема что.. Нет, правильнее будет сразу скриншот показать.

Маркером отмечены сообщения о том, что валидатору не нравятся данные которые вы пытаетесь сохранить через модель. Все хорошо и здорово кроме названия поля в сообщениях. Смышленый пользователь конечно способен догадаться что за поле имеется ввиду, но очевидно чем больше полей в исходной форме, тем сложнее придется пользователю. Да и как-то.. в общем перфекционисты от этого страдают. Есть "способ вылечить" это (на самом деле документированная возможность). Выглядит это примерно так.

public function isValid()
{
  $validator = Validator::make(
    $this->toArray(),
    [
      'name' => 'required',
      'full_link' => 'required|url|unique:table_links,full_link,' . $this->id,
    ]
  );

  $validator->setAttributeNames([
    'name' => 'Название ссылки',
    'full_link' => 'Ссылка для подсчета кликов',
  ]);

  if ($validator->fails()) {
    $this->errors = $validator->errors();
  }

  return $validator->passes();
}

Теперь сообщения будут выглядеть вот так

Стало куда веселее. Осталось почитать оф. документацию по валидации.
Метод setAttributeNames можно поискать в API, он там есть, но описание скромненькое конечно.
Что касается метода isValid, то это метод модели который используется для валидации вот так

public static function boot()
{
  parent::boot();

  // before update and create
  MyModel::creating(function($item) {
    if (!$item->isValid()) return false;
  });

  MyModel::saving(function ($item) {
    if (!$item->isValid()) return false;
  });
}

То есть на модель вешаются хуки, как видно на события сохранения и создания объекта, которые собственно и вызывают наш метод валидации при соответствующих обстоятельствах.
Пример использования такой модели в контроллере выглядит примерно так

public function itemSave()
{
  $item = MyModel::find(Input::get('id'));
  if (!$item) {
    App::abort(404);
  }

  $item->name = Input::get('name');
  $item->full_link = Input::get('full_link');

  if (!$item->save()) {
    return Redirect::route('item-edit', [$item->id])->withErrors($item->errors);
  }

  return Redirect::route('item-edit', [$item->id])->withItemSaved(1);
}

Пример я упростил, но суть та же. Если сохранение отработало с ошибкой, возвращаемся назад с ошибками из валидатора, иначе всё тип-топ, сообщаем об успешном сохранении. Это всё.

P.S.: Для поддержки языковых версий можно вписывать названия свойств вот так

$validator->setAttributeNames([
  'name' => Lang::get('error.name'),
  'full_link' => Lang::get('error.full_link'),
]);