docker в Ubuntu через прокси

Чтобы в свою очередь docker мог в ubuntu работать через proxy редактируем файл /etc/default/docker в самый конец добавляем

export http_proxy="http://login:password@host:port"
export https_proxy="http://login:password@host:port"

и перезапускаем службу docker

$ sudo service docker restart

После этого можно проверить hello-world

$  sudo docker run hello-world

Работа apt-get в Ubuntu через прокси

Чтобы apt-get в Ubuntu заработал через прокси, необходимо создать или добавить в файл

/etc/apt/apt.conf.d/proxy

Следующие строчки:

Acquire::http::Proxy "http://login:password@host:port";
Acquire::ftp::Proxy "http://login:password@host:port";
Acquire::::Proxy "true";

И все заработает

Решение проблемы с PowerShell

Возникла проблема PowerShell «не удается загрузить файл так как выполнение скриптов запрещено для данной системы»

Решается выключением нафиг этой защиты

Set-ExecutionPolicy Unrestricted

О фреймворках JavaScript’овых

В последнее время наблюдаю ситуацию, когда на JavaScript’е пытаются сделать все, что только можно. Тенденция на самом деле пугающая. Популярность понятна – низкий порог вхождения; отсутствие строгих требований к пониманию того, как работают программные системы и распространенность инструментарий (фактически для начала нужен хром и блокнот). Однако, «программисты» на JavaScript’е большей частью люди, далекие от серьезной разработки (существуют конечно и уважаемые гуру, но их как правило гораздо меньше) пишут свой код бездумно и в больших количествах. И очень часто этот код попадает в рабочие проекты. И после этого, когда дело доходит до того, что «система не работает» с этим приходится разбираться. Для того, чтобы немного систематизировать информацию и, дай бог, уменьшить количество такого кода и предназначена эта статья.

Но для начала немного терминологии, которую будем использовать в этой статье. Разделим все Web-страницы, Web-сайты и Web-приложения на два «лагеря» – backend-ориентированные и frontend-ориентированные.

Backend-ориентированные в вопросах обработки бизнес-информации и бизнес-логики опираются на бэкенды, которые написаны как правило на таких языках как Java, PHP, Ruby, Python и даже C++ (надеюсь никого не обидел). Представление в таких приложения как правило не требует каких-то более серьезных вещей кроме как динамика представления данных, обработка событий пользователя и передача их на бэкенд.

Frontend-ориентированные приложения как правило оставляют бэкенду только вопросы взаимодействия с базой данных или другими приложениями и реже вопросы формирования самих представлений. Основная часть работы в таких приложениях ложится на непосредственно frontend, где необходимо кроме собственно динамики представления обеспечивать такие вещи как формирование представлений (сиречь HTML код), обработку переходов и взаимодействия между несколькими представлениями, получение и кэширование данных. Да что там говорить, вообщем-то весь MVC переезжает во Frontend.

Какой подход лучше зависит от многих факторов. Для начала давайте рассмотрим предположительные плюсы и минусы каждого подхода

Backend-ориентированные:

Плюсы:

• Бизнес-логика работает как правило на более структурированных и более производительных технологиях, нежели JavaScript, который хоть и кажется универсальным, достаточно медленен. (Поправка: в последнее время с развитием технологии V8 на некоторых задачах бэкенд на JS иногда даже рвет например Java)
• Бизнес-логика скрыта от конечного пользователя и заниматься ее реверсом (reverse engineering) он не имеет возможности
• Как правило в силу большей «взрослости» и более высокого порога вхождения, бэкенды как правило лучше спроектированы и реализованы
• Благодаря тому, что код бэкенда работает в известном окружении и управляется квалифицированными людьми, допустимые использования как правило шире, чем на JavaScript’е в браузере (который работает в песочнице)
• Как правило стеки технологий для реализация бэкендов закончены и самостоятельны, как правило вам приходится работать с одной определенной версией стека, следовательно вы можете давать некие гарантии надежности

Минусы:

• Как правило более сложная разработка, связанная с временем компиляции и более витиеватым развертыванием (привет долгие редеплои на сервере приложений и известная отмазка программистов - “мой код компилируется”)
• Более высокий порог вхождения означает более высокую стоимость разработки
• Необходимость фактического перехода между «экранами», которая выглядит как загрузка страницы в браузере, при медленном соединении может быть проблемой

Frontend-ориентированные

Плюсы:

• Низкий порог вхождения – большое количество специалистов, которых вы можете нанять (правда о их квалификации лучше задумываться заранее – скупой платит дважды)
• Ввиде того, что JavaScript – интерпретатор, возможна практически интерактивная разработка (а особенно если смотреть в сторону новомодных технологий, которые даже автоматом перерисовывают экран не меняя данные и путь к этому экрану - привет redux)
• Инструменты в виде браузера хром весьма и весьма хороши
• Отсутствие необходимости перезагружать страницу в браузере

Минусы:

• Скорость работы. Когда вы запускаете сложное MVC приложение со всей логикой запущенной в JavaScript, производительность решения оказывается как правило ниже плинтуса
• Спагетти код. Будьте готовы, низкий порог вхождения и отсутствие привычки думать перед написанием кода приводят к печальным результатам
• Чтобы исправить ситуацию, вам надо будет все переписать
• Количество браузеров практически неисчислимо, кроме собственно разных вендоров и их моделей (хром, файрфокс, опера, сафари и т.д.) вы имеете дело практически со всеми известными версиями этих браузеров, а чего стоят версии программы для скачивания браузеров версий 5.5, 6.0, 7.0 и т.д., которые практически несовместимы друг с другом, а ребро так и вообще некий непонятный зверь. Гарантии надежности, даже самые простые вы давать не можете.

Теперь, когда мы определились с терминами скажу свое слово относительно фреймворков. Честно говоря лично мне в данный момент они кажуться чем-то странным и ненужным, но требование объективного изложения требуют от меня аргументации. Что ж попробуем.

Принцип работы Backend-ориентированного приложения

• Все приложение разделяется на набор «экранов», выполняющих небольшую, но законченную функцию
• Представление (HTML) каждого такого экрана формируется на бэкенде, в том числе вспомогательные окна, сообщения и т.д. (тут кстати возможна простая локализация)
• Динамика описывается в виде сценариев JavaScript и описывает только конкретный «экран». Код нескольких «экранов» разделен на уровне JavaScript файлов
• Клиент запрашивает такой экран вместе с необходимыми представлениями и дополнительным программным кодом, обеспечивающим динамику
• ВСЯ сложная обработка обеспечивается на бэкенде и запрашивается представлением посредством AJAX запросов

Принцип работы Frontend-ориентированного приложения

• Бэкенд обеспечивает только отдачу статического содержимого и обработку запросов к источникам данных (БД, …)
• Все представления (в том числе отображаемый HTML) формируется в процессе отображения данных в браузере, что вызывает необходимость переноса таких вещей как модель и контроллер фактически в код представления на JavaScript
• После того, как клиент получил статику и сформировал представления на стороне клиента, AJAX запросы к серверу делаются исключительно при необходимости работы с источником данных
• Собственно, исходя из всего вышеизложенного вытекает инструментарий.

Для Backend-ориентированных:

• J2EE, Spring MVC, JSP – для бэкенда
• Twitter Bootstrap, jQuery, Knockout (или другой binding-фреймворк) – для динамики фронтенда

Большего не нужно, этого вполне хватает для разработки качественных backend-ориентированных приложений.

Для frontend-ориентированных

• Любой Web-сервер – для отдачи статики не важно, какой у вас там сервер, хоть с локальной файловой системы запускайтесь
• %любой JavaScript фреймворк% – любой из новомодных, а потому может быть еще сырых. Выбирайте любой

Иногда вам все же понадобиться что-то, работающее с базой данных. Конечно если вы не используете какой-нибудь MongoDB у которого есть REST-интерфейс

На этом все, можете писать комментарии – по ходу пьессы буду дополнять сий опус.

Переименование виртуальной машины с DB2

Случилось несчастье – пришлось переименовать виртуальную машину на которой была запущена DB2. После этого DB2 отказалась запускаться со словами

«db2start : SQL1022C There is not enough memory available to process the command.».

С учетом свободных 6 ГБ оперативной памяти было ясно, что проблема не в ней. После некоторого гугления был найден рецепт. Тут привожу его перевод.

Изначальное виртуалка называлась пусть VM1, после переименования стала VM2 (названия естественно изменены). Что сделать чтобы чудо случилось:

В C:\Windows\system32\drivers\etc\hosts добавляем строки

127.0.0.1 VM1
127.0.0.1 VM1.company.com

где company.com – ваш домен.

Далее поиском ищем db2nodes.cfg и заменяем там VM1 на VM2, должно получиться примерно так

0 VM2 VM2 0

Далее запускаем редактор реестра (regedit) и навигируемся сюда

HKLM\Software\IBM\DB2\GLOBAL_PROFILE

Правим

DB2_ADMINGROUP "VM1\DB2ADMINS" -> "VM2\DB2ADMINS"
DB2_USERSGROUP "VM1\DB2USERS" -> "VM2\DB2USERS"
DB2SYSTEM "VM1" -> "VM2"

После этого перезагружаемся и все должно работать…

И не работает …

Надо сделать еще вот что:

$ db2extsec -r
$ db2extsec /a DB2ADMNS /u DB2USERS

После этого все заработало