Станислав Б

в математике полный ноль

Начать с решения данной проблемы.

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

Главное отличие - ваша рабочая и личная переписка разделена. В телеграме мем от друга в личку может занять вас на пару минут. В слэке тоже можно, но это будет значить, что ваш коллега целенаправленно хотел вас порадовать свежим мемасиком.

В слэке компании разделены серверами, и это больше похоже на Discord, только для работы. На каждом сервере есть каналы, для каждого канала можно очень гибко настроить уровни доступа и режим уведомлений (даже с учётом временной зоны работника, никто вам ночью не пришлёт нервное письмо с правками)

Пробежимся по плюсам:
1. Каждый работник может настроить себе кастомные уведомления. Типа

уведомлять меня, когда кто-нибудь напишет "синхрофазотрон" или назовет меня по имени

2. Можно шарить снипеты с подсветкой синтаксиса множества языков и другие вложения
3. Поддержка сторонних сервисов. Ссылки с гуглодоков и других сервисов могут обрабатываться прямо в слэке (например, можно отметить выполненным таск в Asana сообщением в Slack, некоторым удобно)
4. Адекватный бот, с веб-хуками и прочими плюшками.

А теперь про минусы:
1. Нативное приложение очень заметно жрет оперативку
2. Бесплатно доступны для поиска только последние 10000 сообщений (не такой уж прям критичный минус, если не держать флудилку на том же серваке)
3. Нет стикерпаков и видеосообщений в кружочках =(

Здравствуйте!

Странно, что вопрос поставлен именно так, а не "почему дизайнер должен знать историю искусства?".
Неужели умение отличать барокко от рококо или элинизм от архаики вам чем-то поможет в, грубо говоря, прорисовке макетов, логотипов или в составлении айдентики? Пол Рэнд, известный американский дизайнер, в своих книгах теоретический фундамент выстраивает на собственных знаниях по философии. Например, дедуктивный способ познания Декарта отлично проясняет метод работы дизайнера — от общего к частному.

Мысль о том, что дизайнер обязан понимать картины Анатолия Зверева или Кокошки, высосана из пальца студентами художественных вузов, которых еженедельно пичкали новыми "измами". Я сам из таких. Бесспорно нужно знать историю дизайна, то есть историю искусств с конца 19 века, когда появились авангардисты и модернисты. Нужно понимать как работает Золотое Сечение, как работают Числа Фибоначчи, понимать теорию цвета (Иттен), основы типографики (Джеймс Крейг). Владеть инструментами, которыми вы сможете свои идеи воплотить. Зачем вам знать, что такое фаюмские портреты — я не понимаю.
Я не отрицаю того, что люди должны быть эрудированы разносторонне, но говорить, что знание истории искусства для дизайнера — аксиома. Этого я не понимаю. Дизайнер — это утилитарная профессия, которая решает определённые задачи. Рембрандт тоже решал задачи, поставленные заказчиком ("покажи, что ночной дозор - крутые перцы"), но Рембрандт это делал, не ориентируясь на покупательную способность аудитории, на контраст, на контекст, на концепт. Заказчик платил за то, чтобы это сделал Рембрандт так, как это делает Рембрандт.

В общем, вот "лёгкие" книги по истории искусствa:

1. История искусствa Гомбрих
   
2. Введение в историческое изучение искусства Виппер
   
3. МХК. Учебник для 10 класса. Емохонова.
   

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

https://www.google.com.ua/search?q=site%3Atoster.r...

Расшифровывать ничего не нужно, просто избавьтесь от вируса, который поймали. В таком коде обычно зашифровывается спам рассылка, редиректы, скачивание других вирусов к вам на сайт и прочая хрень. Восстановите свой файл из бэкапов, потому что некоторые вирусы заменяют файлы целиком (ваш вариант), а некоторые просто дописывают меньший по объему код в начало файла.

preg_match('/([1-9]|1[0-2])/', $string)

В кодировке! Что, блин, логично само по себе.

Связано ли это как-то с поисковой оптимизацией или просто тестируют юзабилити таким образом?

Конечно это только тест ui/ux. Проект с большой аудиторией рискует ее потерять если новый дизайн окажется не удобным.
Отличный пример "Кинопоиск", когда яндекс его купил и сделал редизайн (настолько плохого ui я еще не видел) многие отказались и им это стоило больших денег. Они вернули старый, но потеряли аудиторию на какое-то время, а это много денег. Выкатили бы на новый домен, все было бы иначе.
Youtube меняет интерейс и он давно уже как бета, но народ не воспринимает его.
Не обязательно иметь поддомен для этого, можно решать настройками пользователя, куками или еще как. Главное что есть возможность включить старый вариант.

сперва были вопросы "как стать программистом"
затем вопросы "что читать"
теперь уже "как читать"
может скоро будет "как учить алфавит, а то за меня родители пишут на тостере".

Для книг - читайте простейшие туториалы и сразу практика. Сложные книги - потом, когда в голове уже будет база.

Добавлю еще момент:
Почитайте статью megamozg.ru/post/10126
Там очень понятно указано, что профессиональный навык и боль программиста - гиперконцентрация, которая необходима, чтобы освоить понятия и вещи для профессиональной работы. 40 минут это как-то несерьезно.

Друзья, как вы настраиваете навигацию в нотпад++ при работе с css?

а мы не работаем с css через NotePad++. Это же мазохизм. Есть ide типа webStorm или бесплатный, но корявый sublime text или бесплатный, но менее корявый atom.

42

Python - прост в обучение, куча батареек, с кроссплатформленностью нету проблем

Работаете в ветке dev, периодически вливая ее в master. Для крупных задач (не входящих в один коммит) делаете отдельные ветви из dev.

Вливая dev в master, делаете это с ключом --squash как то так:

git checkout master
git merge --squash dev

Тут теоретически могут быть конфликты, если вы делали коммиты в masterпараллельно с dev, которые вам надо разрешить, а после уже добавляете и делаете один большой коммит:

git add -A
git commit -m "Merged dev: %кратко (или нет) основные изменения%"
git push

А чтобы не мозолили глаз висящие коммиты с логической незавершенностью, их можно сливать их перед merge с помощью интерактивного rebase:

git checkout dev
git rebase -i master

Откроется редактор, в котором будет список коммитов ветки dev. Здесь можете слепить ненавистные коммиты с помощью команды squash (и тогда вам предложат отредактировать сообщение) или fixup (тут не предложат) и потом сделать git push --force (для одного не критично, в толпе лучше использовать --force-with-lease.

Или есть еще вариант - лепить к предыдущему коммиту сразу с помощью git commit --amend

Ну и после merge уже можете на master лейбл версии повесить.