Спасибо за ёмкий ответ! Расскажу немного про наш велосипед К сожалению, система полностью закрытая, разрабатывалась под заказ для нужд одного университета У нас на данный момент реализованы только html/css/js (причём js только клиентский), что позволило полностью изолировать бэк от возможных проблем, потому что код исполняется в браузере У нас была задача с прогоном клиентских тестов, которую мы решали путём создания iframe sandbox'a, в котором специальным образом запускался код пользователя с инъекцией туда служебных вставок для прогона тестов, которые писались вместе с заданием нашими преподавателями В целом система получилась по части бэка крайне легковесная, сложным был именно клиент в виду специфики создания там sandbox
Сейчас же мы планируем запуск курсов с использованием серверных вычислений и с компиляцией клиентского кода, чтобы преподаватели могли составлять курс по React JS Именно поэтому мой комментарий содержит столько вопросов, потому что нам лишь предстоит пройти этот тернистый путь Правильно ли я понимаю вашу схему организации: 1. В хостовой системе создаётся учётный пользователь с ограниченными правами, от имени которого выполняется сборка и запуск контейнера? Т.е. по сути добавляете в группу docker некоего пользователя, который ограничен в хосте только своей домашней директорией 2. Dockerfile содержит в себе необходимый минимум, сборка (при необходимости) пользовательского кода происходит в контейнере 3. Ограничение исполнения устанавливается путём, видимо, энтрипоинта с установкой линуксового таймаута 4. При работе с файлами перед запуском пользовательского кода домашняя директория очищается и монтируется к контейнеру с правами записи
Из 4 пункта следует вопрос - а как у вас дела с параллельностью? Т.е. все прогоны пользовательского кода как-то распланированы? Чем планируете? Некие queue с последовательным исполнением? Есть ли реальный параллелизм и на какое конкурентное исполнение вы нацелены? И в случае конкурентности следует вывод, что количество конкурентных прогонов равно количеству пользователей от имени которых гоняют запуск кода
И ещё открытый вопрос - это прогон тестов Очевидно, на вход нужно давать некий ввод, на выход ловить какой-то выхлоп Для задач без файловой системы вроде бы звучит просто, перехватил прям в контейнере stdin/stdout и работаешь В ряде случаев даже можно писать stdout в файл и парсить, чтобы не оборачивать программу в какой-то враппер (тут кстати тоже потенциальная дыра, особенно в части stdout, потому что в зависимости от стека можно добиться исполнения произвольного кода, ну да не суть) Т.е. всегда ли у вас прямо внутри контейнеров запускается прогон тестов, потому что нужно давать ввод и читать вывод Или вы снаружи контейнера это делаете, путём энтрипонтов или аргументов docker run? А вот при работе с файловой системой становится очень очевидно. С одной стороны похоже на чтение ввода вывода, а с другой совсем нет, потому что можно работать как внутри, так и снаружи, причём абсолютно по разному (и на ЯП, и на линуксовых командах, и перехватом запросов к файловой системе)
В ооооообщем, очень интересная тема для беседы И мне кажется, что описание серверной части достойно отдельной статьи, потому что там вы решали очень интересные задачи С радостью бы почитал, а может и смог бы помочь в решении каких-то особенных задач
Привет! Мы с командой тоже делали сервис для изучения ЯП Интересно в этой цепочке узнать у вас какие-то детали по работе с Docker и изоляцией запускаемого кода Как контролируете запускаемый код по выделяемым ресурсам (таймауты, лимиты по CPU/ОЗУ)? Какие образы используете (наверное что-то на базе alpine)? Много ли у вас заготовленных образов под разные задачи или под каждую задачу просто делаете Dockerfile с чем-то типа FROM base-image? Сразу ли чистите собранные контейнеры? Есть ли у вас в цикле курса работа с файловой системой? Если да, то при работе с ней в запускаемом коде как работаете с Docker? Даёте право на запись файлов? Или только чтение? Боретесь ли как-то с возможными угрозами в коде? Можно ведь выйти за границы контейнерной изоляции и запустить что-то в ядре хоста
Эта часть намного интереснее всего остального на мой взгляд) Будет интересно почитать, если на что-то ответите
Лично в моем опыте werf со своим "гитермизмом" в ряде случаев становился проблемой. Инструмент, безусловно, отличный. Пайпы выглядит проще, трассировка процесса доставки очень хорошо и красиво выводится в лог job'ы в Gitlab. Но если появляется потребность в лёгкой гибкости и вам нужно внедрить что-то дополнительное в процессе сборки/деплоя, то начнется сущий ад.
Не отрицаю, опыта с werf у меня недостаточно и в случае, если вы опытный читатель, то буду рад конструктивным рекомендациям по эксплуатации данного инструмента)
@pronskiy - После установки PHP8.1-RC6 на локальном окружении столкнулся с проблемой, не сталкивались ли Вы? Вот детали по окружению:
❯ php -v
PHP 8.1.0RC6 (cli) (built: Nov 11 2021 19:52:08) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.0-dev, Copyright (c) Zend Technologies
with Zend OPcache v8.1.0RC6, Copyright (c), by Zend Technologies
❯ uname -a
Linux DESKTOP-I5PMM46 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
❯ dpkg-query -l | grep -i php8.1
ii libapache2-mod-php8.1 8.1.0~rc6-1+ubuntu20.04.1+deb.sury.org+1 amd64 server-side, HTML-embedded scripting language (Apache 2 module)
ii php8.1 8.1.0~rc6-1+ubuntu20.04.1+deb.sury.org+1 all server-side, HTML-embedded scripting language (metapackage)
ii php8.1-cli 8.1.0~rc6-1+ubuntu20.04.1+deb.sury.org+1 amd64 command-line interpreter for the PHP scripting language
ii php8.1-common 8.1.0~rc6-1+ubuntu20.04.1+deb.sury.org+1 amd64 documentation, examples and common module for PHP
ii php8.1-opcache 8.1.0~rc6-1+ubuntu20.04.1+deb.sury.org+1 amd64 Zend OpCache module for PHP
ii php8.1-readline 8.1.0~rc6-1+ubuntu20.04.1+deb.sury.org+1 amd64 readline module for PHP
В результате Composer начал ломаться во всех местах. Даже вызов -v вызывает краш:
При перестановке Composer под чистую валиться что-то вроде:
❯ php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
❯ php composer-setup.php
Warning: preg_match(): Compilation failed: unrecognised compile-time option bit(s) at offset 0 in /home/khazhinov/composer-setup.php on line 461
All settings correct for using Composer
Downloading...
Warning: preg_replace(): Compilation failed: unrecognised compile-time option bit(s) at offset 0 in /home/khazhinov/composer-setup.php on line 1252
Warning: preg_replace(): Compilation failed: unrecognised compile-time option bit(s) at offset 0 in /home/khazhinov/composer-setup.php on line 1252
Warning: preg_replace(): Compilation failed: unrecognised compile-time option bit(s) at offset 0 in /home/khazhinov/composer-setup.php on line 1252
Warning: preg_replace(): Compilation failed: unrecognised compile-time option bit(s) at offset 0 in /home/khazhinov/composer-setup.php on line 1252
Warning: preg_replace(): Compilation failed: unrecognised compile-time option bit(s) at offset 0 in /home/khazhinov/composer-setup.php on line 1252
...
Великое и могучее "чем бы заняться" в сочетании с высоким интеллектом меня всегда впечатляет. Круто! Спасибо за детальное пояснение в статье и отснятый материал. Всегда впечатляет и пугает, какие могут быть соседи!)
Спасибо!
Но единственный минус привыкания к новым утилитам в замен старым — их нужно ставить
Когда у тебя 10+ серверов в разных инфраструктурах и ты привыкаешь к таким вариантам — эффективность использования консоли может резко упасть на нет
Пока писал комментарий, понял — нужно написать утилиту «установщик», которая умеет смотреть в репозиторий для подтягивания конфига.
Выложить эту утилиту в самые распространённые дистрибутивы, научить её подтягивать конфиг со своего репо с настройкой (так можно под рукой держать несколько репозиториев с разными пресетами) и одной командой устанавливать на сервер то, что описано в пресете.
А ещё уметь обновляться нужно. Например — обновляешь свой пресет, логинишься в консоли и утилита автоматически посмотрит в использованный ранее пресет и увидит, что что-то изменилось и предложит доустановить.
Если есть такое — дайте ссылку, буду очень благодарен.
Однажды разрабатывал сервис, в котором было очень много контента на английском языке и клиент захотел внедрить Google Translate с целью получения мультиязычного контента и обширного списка контента на разных языках. Цель такая — клиент пишет статью на английском и система автоматически переводит полученный текст на все разрешенные локали (20 штук).
На тот момент времени у Googlte Translate API не было интерфейса для перевода входящего текста в массив локалей, можно было переводить только один текст на одну локаль.
В связи с этим весь перевод стал фоновой задачей. Т.е. было некоторое число воркеров, которые работали над задачами перевода вне запросов потребителей.
Появилась необходимость сделать так, чтобы можно было добавлять новую локаль максимально быстро. Т.е. взять и перевести весь имеющийся контент одной командой на новую локаль и добавить в базу. И вот однажды мой коллега сделал это в системе перевода, я быстренько заревьювил и проблем не нашел. Выкатили в прод, подняли, всё заработало.
Через 3 дня пишет клиент и говорит, что ему прилетел счёт от Google в размере $10000.
Оказалось, система в цикле начала переводить один и тот же контент. Раз за разом.
Кредитку отвязали, аккаунт удалили и забыли)
Но в первые дни было ужасно страшно!
Спасибо за обзор моделей и цен, узнал пару новых девайсов для собственного использования!
Используете ли Вы подобные устройства у себя на работе или дома? Если да, то какие задачи решаете?
Лично я организовываю из дома VPN туннели через Intel Nuc и по чуть-чуть изучаю вопросы автоматизации домашних задач с использованием RPI 4 model B (смотрю разные реализации умного дома).
Но чем эта статья помогает «лучше организовать свою безопасность в Интернете»?
Думаю, ни для кого не секрет, что существуют подобные «мини-компьютеры».
Однако, соглашусь с комментариями выше — их использование ориентировано на обычное использование или на цели бизнеса и доступ к устройствам доступен в обычном интернете. Большая часть выше представленных ссылок (если не все) ведь не требуется привилегированного доступа к ресурсам.
Эта история заслуживает фильма.
Прочитал на одном дыхании. В свое время увлекался темой пластичности мозга, очень зацепила одноименная книга Нормана Дойджа.
В процессе изучения данной темы натыкался на описания описанного в статье заболевания, но никогда не читал истории из жизни близких к пациенту людей, лишь медицинские заметки.
Спасибо за отличный перевод отличной статьи.
Когда я делал Forge, я слышал от нескольких людей критику из разряда — каждый может это сделать с помощью Ansible или ExpertVison, самостоятельно хостить и управлять скриптами. Про Homestead говорили, что можно создать Vagrant-файл с баш-командами, и вот тебе среда разработки для работы с Laravel.
Думаю, многие могут сказать, что все эти инструменты являются усложнением уже устоявшихся и удобных в нативном виде технологий.
Лично для меня многие инструменты из мира экосистемы Laravel стали значительным облегчением повседневных задач. Vagrant с Homestead использую каждый день при работе с php проектами, хотя далеко не всегда нужно что-то большее, чем «php -S localhost:8000»
Но стоит не забывать о том, что Homestead создана для создания именно Laravel приложений (хотя нет никаких ограничений в использовании и без Laravel, можно без проблем поднять и любое другое php приложение)
Тем не менее, не могу найти аналогов Homestead, в которых было бы ещё проще создавать для себя окружение, в котором есть всё необходимое для разработки какого-то не совсем простого PHP приложения. Из коробки есть всё необходимое, а установка Virtualbox + Vagrant не занимает больше 5 минут в любом окружении. Уже буквально через 10 минут мы имеем полностью готовое к работе окружение, которое ничем не отличается от того, что используем дома/на работе)
В общем, на вкус и цвет, конечно. Но я, лично, выражаю дань уважения к разработчикам всех продуктов из экосистемы Laravel. Как минимум за то, что дают возможность такой большой аудитории поработать с чем-то интересным абсолютно бесплатно.
Просто вау
Разместить такое вместо фона в безрамочном терминале и получится рабочий стол по круче любого хакера из сериала)
Сразу вопрос. Есть ли пробная конфигурация для сбора метрик с локальной машины (CPU, ОЗУ и т.д.) под Windows?
Прекрасное обновление. Деплой на группы серверов очень порадовали, давно ждал такой возможности. И сохранение вкладок терминала при закрытии IDE — тоже очень юзабельно.
Было бы очень неплохо ещё чуть-чуть расширить функционал вкладок терминала. Например, добавить возможность конфигурирования отдельных вкладок или что-то вроде скриптов, чтобы можно было не просто сохранять путь вкладки, а так же выполнять команды при запуске.
В большинстве проектов я использую Vagrant для поднятия нужных мне виртуалок и при запуске IDE я как правило сначала выполняю ряд рутинных задач, вида: «открыть такую-то папку, запустить такую-то машинку, подключиться к ней по SSH, перейти в папку проекта на машинке и блаблабла».
Если есть какие-то плагины, дающие возможность реализовать подобный функционал, буду очень рад комментариям.
p.s. есть маленький lifehack для студентов(и не только), желающих получить полный набор софта от JetBrains за бесплатно
Это классический студенческий набор, который поставляется вместе с предоставлением студенческого. Но есть одна особенность. Валидацию на студента можно проходить не только в JetBrains, но и на GitHub ТЫК
Почему я говорю, что не только студенты могут воспользоваться привилегией? Всё благодаря тому, что при прохождении валидации на сайте JetBrains к проверке относятся достаточно ответственно, чего не сказать о GitHub. Как-то с товарищами тестировали получение этого студенческого набора без студенческого билета, используя фотографии перваков, которые любезно выкладывают фотографии своих студенческих в социальные сети, помечая их тонной тегов для удобного и быстрого поиска.
После подтверждения статуса студента на GitHub Education, переходим по ссылке ТЫК и дальше всё интуитивно понятно.
Конечно, этот способ не должен стать примером того, как нужно делать и вообще так делать не стоит, но… Для разработчиков, которым не хватает средств на покупку лицензии, это хороший выход и хоть какая-то возможность пользоваться действительно крутыми IDE без возни с кряками и прочим шлаком.
story: Переехал на PhpStorm летом этого года и влюбился. Когда-то давно попробовал им воспользоваться и тогда мне данная IDE показалась до жути не удобной и слишком тяжелой. Покупка нового ПК перевернула взгляд на PhpStorm в лучшую сторону, ибо теперь я могу работать одновременно с несколькими виртуальными машинами, браузером и IDE, не теряя ни капли производительности. Заложенный в PhpStorm DataGrip стал для меня крайне приятной особенностью, т.к. во время разработки крайне удобно использовать автоподстановку в SQL-запросах в проектах, где не убежать от сложных названий таблиц и полей. Расположение на экране элементов делает разработку приятной, не превращая экран в билборд, от которого рябит в глазах. На очень даже компактно помещаются: дерево файлов, окно редактора, окно DataGrip и терминал, особенно когда узнаешь парочку самых горячих комбинаций клавиш.
Одним из самых решающих для меня факторов стало то, что 95% функционала, который нужен при разработке, заложено из коробки и необходимость что-то докачивать/настраивать настигает крайне редко.
Спасибо за ёмкий ответ!
Расскажу немного про наш велосипед
К сожалению, система полностью закрытая, разрабатывалась под заказ для нужд одного университета
У нас на данный момент реализованы только html/css/js (причём js только клиентский), что позволило полностью изолировать бэк от возможных проблем, потому что код исполняется в браузере
У нас была задача с прогоном клиентских тестов, которую мы решали путём создания iframe sandbox'a, в котором специальным образом запускался код пользователя с инъекцией туда служебных вставок для прогона тестов, которые писались вместе с заданием нашими преподавателями
В целом система получилась по части бэка крайне легковесная, сложным был именно клиент в виду специфики создания там sandbox
Сейчас же мы планируем запуск курсов с использованием серверных вычислений и с компиляцией клиентского кода, чтобы преподаватели могли составлять курс по React JS
Именно поэтому мой комментарий содержит столько вопросов, потому что нам лишь предстоит пройти этот тернистый путь
Правильно ли я понимаю вашу схему организации:
1. В хостовой системе создаётся учётный пользователь с ограниченными правами, от имени которого выполняется сборка и запуск контейнера? Т.е. по сути добавляете в группу docker некоего пользователя, который ограничен в хосте только своей домашней директорией
2. Dockerfile содержит в себе необходимый минимум, сборка (при необходимости) пользовательского кода происходит в контейнере
3. Ограничение исполнения устанавливается путём, видимо, энтрипоинта с установкой линуксового таймаута
4. При работе с файлами перед запуском пользовательского кода домашняя директория очищается и монтируется к контейнеру с правами записи
Из 4 пункта следует вопрос - а как у вас дела с параллельностью? Т.е. все прогоны пользовательского кода как-то распланированы? Чем планируете? Некие queue с последовательным исполнением? Есть ли реальный параллелизм и на какое конкурентное исполнение вы нацелены? И в случае конкурентности следует вывод, что количество конкурентных прогонов равно количеству пользователей от имени которых гоняют запуск кода
И ещё открытый вопрос - это прогон тестов
Очевидно, на вход нужно давать некий ввод, на выход ловить какой-то выхлоп
Для задач без файловой системы вроде бы звучит просто, перехватил прям в контейнере stdin/stdout и работаешь
В ряде случаев даже можно писать stdout в файл и парсить, чтобы не оборачивать программу в какой-то враппер (тут кстати тоже потенциальная дыра, особенно в части stdout, потому что в зависимости от стека можно добиться исполнения произвольного кода, ну да не суть)
Т.е. всегда ли у вас прямо внутри контейнеров запускается прогон тестов, потому что нужно давать ввод и читать вывод
Или вы снаружи контейнера это делаете, путём энтрипонтов или аргументов docker run?
А вот при работе с файловой системой становится очень очевидно. С одной стороны похоже на чтение ввода вывода, а с другой совсем нет, потому что можно работать как внутри, так и снаружи, причём абсолютно по разному (и на ЯП, и на линуксовых командах, и перехватом запросов к файловой системе)
В ооооообщем, очень интересная тема для беседы
И мне кажется, что описание серверной части достойно отдельной статьи, потому что там вы решали очень интересные задачи
С радостью бы почитал, а может и смог бы помочь в решении каких-то особенных задач
Привет!
Мы с командой тоже делали сервис для изучения ЯП
Интересно в этой цепочке узнать у вас какие-то детали по работе с Docker и изоляцией запускаемого кода
Как контролируете запускаемый код по выделяемым ресурсам (таймауты, лимиты по CPU/ОЗУ)?
Какие образы используете (наверное что-то на базе alpine)? Много ли у вас заготовленных образов под разные задачи или под каждую задачу просто делаете Dockerfile с чем-то типа
FROM base-image? Сразу ли чистите собранные контейнеры?Есть ли у вас в цикле курса работа с файловой системой? Если да, то при работе с ней в запускаемом коде как работаете с Docker? Даёте право на запись файлов? Или только чтение?
Боретесь ли как-то с возможными угрозами в коде? Можно ведь выйти за границы контейнерной изоляции и запустить что-то в ядре хоста
Эта часть намного интереснее всего остального на мой взгляд)
Будет интересно почитать, если на что-то ответите
Добрый день, Олег!
Надеюсь, вы взыскали ответы на свои вопросы спустя столько времени.
P.S. Если что, ты уж пиши мне в скайпе иногда, буду рад помочь!
Лично в моем опыте werf со своим "гитермизмом" в ряде случаев становился проблемой. Инструмент, безусловно, отличный. Пайпы выглядит проще, трассировка процесса доставки очень хорошо и красиво выводится в лог job'ы в Gitlab. Но если появляется потребность в лёгкой гибкости и вам нужно внедрить что-то дополнительное в процессе сборки/деплоя, то начнется сущий ад.
Не отрицаю, опыта с werf у меня недостаточно и в случае, если вы опытный читатель, то буду рад конструктивным рекомендациям по эксплуатации данного инструмента)
А так - helm всему голова!
@pronskiy - После установки PHP8.1-RC6 на локальном окружении столкнулся с проблемой, не сталкивались ли Вы?
Вот детали по окружению:
В результате Composer начал ломаться во всех местах. Даже вызов -v вызывает краш:
При перестановке Composer под чистую валиться что-то вроде:
Нашел вчерашний Issue - https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1830385.html
Ждём фиксов?
Великое и могучее "чем бы заняться" в сочетании с высоким интеллектом меня всегда впечатляет. Круто! Спасибо за детальное пояснение в статье и отснятый материал.
Всегда впечатляет и пугает, какие могут быть соседи!)
Но единственный минус привыкания к новым утилитам в замен старым — их нужно ставить
Когда у тебя 10+ серверов в разных инфраструктурах и ты привыкаешь к таким вариантам — эффективность использования консоли может резко упасть на нет
Пока писал комментарий, понял — нужно написать утилиту «установщик», которая умеет смотреть в репозиторий для подтягивания конфига.
Выложить эту утилиту в самые распространённые дистрибутивы, научить её подтягивать конфиг со своего репо с настройкой (так можно под рукой держать несколько репозиториев с разными пресетами) и одной командой устанавливать на сервер то, что описано в пресете.
А ещё уметь обновляться нужно. Например — обновляешь свой пресет, логинишься в консоли и утилита автоматически посмотрит в использованный ранее пресет и увидит, что что-то изменилось и предложит доустановить.
Если есть такое — дайте ссылку, буду очень благодарен.
Спасибо, бальзам на душу
Редко когда можно что-то прочитать и думать — это вот прямо про меня
На тот момент времени у Googlte Translate API не было интерфейса для перевода входящего текста в массив локалей, можно было переводить только один текст на одну локаль.
В связи с этим весь перевод стал фоновой задачей. Т.е. было некоторое число воркеров, которые работали над задачами перевода вне запросов потребителей.
Появилась необходимость сделать так, чтобы можно было добавлять новую локаль максимально быстро. Т.е. взять и перевести весь имеющийся контент одной командой на новую локаль и добавить в базу. И вот однажды мой коллега сделал это в системе перевода, я быстренько заревьювил и проблем не нашел. Выкатили в прод, подняли, всё заработало.
Через 3 дня пишет клиент и говорит, что ему прилетел счёт от Google в размере $10000.
Оказалось, система в цикле начала переводить один и тот же контент. Раз за разом.
Кредитку отвязали, аккаунт удалили и забыли)
Но в первые дни было ужасно страшно!
Используете ли Вы подобные устройства у себя на работе или дома? Если да, то какие задачи решаете?
Лично я организовываю из дома VPN туннели через Intel Nuc и по чуть-чуть изучаю вопросы автоматизации домашних задач с использованием RPI 4 model B (смотрю разные реализации умного дома).
Но чем эта статья помогает «лучше организовать свою безопасность в Интернете»?
Думаю, ни для кого не секрет, что существуют подобные «мини-компьютеры».
Однако, соглашусь с комментариями выше — их использование ориентировано на обычное использование или на цели бизнеса и доступ к устройствам доступен в обычном интернете. Большая часть выше представленных ссылок (если не все) ведь не требуется привилегированного доступа к ресурсам.
Эта история заслуживает фильма.
Прочитал на одном дыхании. В свое время увлекался темой пластичности мозга, очень зацепила одноименная книга Нормана Дойджа.
В процессе изучения данной темы натыкался на описания описанного в статье заболевания, но никогда не читал истории из жизни близких к пациенту людей, лишь медицинские заметки.
Спасибо за отличный перевод отличной статьи.
Восторг!
Всегда рад почитать хорошо представленный материал и сложнейших задачах современной науки.
Огромное спасибо автору.
Думаю, многие могут сказать, что все эти инструменты являются усложнением уже устоявшихся и удобных в нативном виде технологий.
Лично для меня многие инструменты из мира экосистемы Laravel стали значительным облегчением повседневных задач. Vagrant с Homestead использую каждый день при работе с php проектами, хотя далеко не всегда нужно что-то большее, чем «php -S localhost:8000»
Но стоит не забывать о том, что Homestead создана для создания именно Laravel приложений (хотя нет никаких ограничений в использовании и без Laravel, можно без проблем поднять и любое другое php приложение)
Тем не менее, не могу найти аналогов Homestead, в которых было бы ещё проще создавать для себя окружение, в котором есть всё необходимое для разработки какого-то не совсем простого PHP приложения. Из коробки есть всё необходимое, а установка Virtualbox + Vagrant не занимает больше 5 минут в любом окружении. Уже буквально через 10 минут мы имеем полностью готовое к работе окружение, которое ничем не отличается от того, что используем дома/на работе)
В общем, на вкус и цвет, конечно. Но я, лично, выражаю дань уважения к разработчикам всех продуктов из экосистемы Laravel. Как минимум за то, что дают возможность такой большой аудитории поработать с чем-то интересным абсолютно бесплатно.
Разместить такое вместо фона в безрамочном терминале и получится рабочий стол по круче любого хакера из сериала)
Сразу вопрос. Есть ли пробная конфигурация для сбора метрик с локальной машины (CPU, ОЗУ и т.д.) под Windows?
Было бы очень неплохо ещё чуть-чуть расширить функционал вкладок терминала. Например, добавить возможность конфигурирования отдельных вкладок или что-то вроде скриптов, чтобы можно было не просто сохранять путь вкладки, а так же выполнять команды при запуске.
В большинстве проектов я использую Vagrant для поднятия нужных мне виртуалок и при запуске IDE я как правило сначала выполняю ряд рутинных задач, вида: «открыть такую-то папку, запустить такую-то машинку, подключиться к ней по SSH, перейти в папку проекта на машинке и блаблабла».
Если есть какие-то плагины, дающие возможность реализовать подобный функционал, буду очень рад комментариям.
p.s. есть маленький lifehack для студентов(и не только), желающих получить полный набор софта от JetBrains за бесплатно
Это классический студенческий набор, который поставляется вместе с предоставлением студенческого. Но есть одна особенность. Валидацию на студента можно проходить не только в JetBrains, но и на GitHub ТЫК
Почему я говорю, что не только студенты могут воспользоваться привилегией? Всё благодаря тому, что при прохождении валидации на сайте JetBrains к проверке относятся достаточно ответственно, чего не сказать о GitHub. Как-то с товарищами тестировали получение этого студенческого набора без студенческого билета, используя фотографии перваков, которые любезно выкладывают фотографии своих студенческих в социальные сети, помечая их тонной тегов для удобного и быстрого поиска.
После подтверждения статуса студента на GitHub Education, переходим по ссылке ТЫК и дальше всё интуитивно понятно.
Конечно, этот способ не должен стать примером того, как нужно делать и вообще так делать не стоит, но… Для разработчиков, которым не хватает средств на покупку лицензии, это хороший выход и хоть какая-то возможность пользоваться действительно крутыми IDE без возни с кряками и прочим шлаком.
story: Переехал на PhpStorm летом этого года и влюбился. Когда-то давно попробовал им воспользоваться и тогда мне данная IDE показалась до жути не удобной и слишком тяжелой. Покупка нового ПК перевернула взгляд на PhpStorm в лучшую сторону, ибо теперь я могу работать одновременно с несколькими виртуальными машинами, браузером и IDE, не теряя ни капли производительности. Заложенный в PhpStorm DataGrip стал для меня крайне приятной особенностью, т.к. во время разработки крайне удобно использовать автоподстановку в SQL-запросах в проектах, где не убежать от сложных названий таблиц и полей. Расположение на экране элементов делает разработку приятной, не превращая экран в билборд, от которого рябит в глазах. На очень даже компактно помещаются: дерево файлов, окно редактора, окно DataGrip и терминал, особенно когда узнаешь парочку самых горячих комбинаций клавиш.
Одним из самых решающих для меня факторов стало то, что 95% функционала, который нужен при разработке, заложено из коробки и необходимость что-то докачивать/настраивать настигает крайне редко.