У меня на Хабре была небольшая, но честно заработанная карма. Когда я начал критиковать безграмотные тексты (ну достали уже!), мне её моментально слили в ноль.
Видимо, безграмотность в современном мире считается не просто допустимой, но даже достоинством.
Да, я неправильно понял задачу, наверное из-за того, что мне ни разу в жизни не приходилось объединять два последних коммита и даже сложно представить, зачем это может понадобиться. А вот amend – регулярно =D.
хеш_коммита_который_ещё_надо_найти
Вроде речь идёт о двух последних коммитах и искать ничего не надо, не? git log -2 – или я опять что-то неправильно понял?
Позволю себе поставить под сомнение Ваше утверждение про критическое мышление.
Такой пример: кричащие заголовки (CAPSLOCK, куча восклицательных знаков, "ШОК!" и т.д.) однозначно указывают на то, что читать это не стоит – вряд ли там будет что-то полезное, если внимание привлекается такими дешёвыми и пошлыми методами.
При этом таких заголовков в интернетах куча, т.е., на них кто-то ведётся, и ведётся массово – иначе авторы текстов подобные заголовки бы не использовали.
Это позволяет сделать вывод, что у большого количества людей критическое мышление недостаточно развито.
Могу предположить за автора, что ему не нравится возникающая в этом случае некоторая дополнительная сложность, например, чтобы извлечь данные по одной сущности из двух таблиц, понадобится дополнительный JOIN.
Поэтому соглашусь, что не стоит использовать "один-к-одному" без веских причин.
Но не соглашусь, что не стоит использовать такую связь вообще никогда, ибо причины всё-таки могут быть.
Ну, тем, кто далёк от проектирования БД, эта терминология незнакома.
Между сущностями (которые в БД превращаются в таблицы) может быть три типа связи (по мощности): один-к-одному, один-ко-многим, многие-ко-многим.
Две таблицы, связанные как "один-к-одному", могут быть объединены в одну без нарушения целостности структуры БД. Такое разделение чаще всего носит технический характер (например, вынести в отдельную таблицу редкоиспользуемые поля большого размера).
Ну, кроме книг по конкретным технологиям, используемым на проекте сейчас или потенциально, я бы на месте начинающего техлида концентрировался на книгах по качеству кода, таких как:
Роберт Мартин – Чистый код. Создание, анализ и рефакторинг.
Стив Макконнелл – Совершенный код.
Мартин Фаулер - Рефакторинг. Улучшение существующего кода.
Д. Босуэлл, Т. Фаучер – Читаемый код.
и т.д.
И, конечно, ещё книги по инженерным практикам: юнит-тестированию (Ошероув, Мессарош, Хориков – !!!), CI/CD (попадалась книга по Jenkins-у) и т.д.
Делиться знаниями -- это одно, а управлять проектами (Демарко, №6 в Вашем списке) или руководить командой (№№1, 2, 5) -- это совсем другое. Так что подборка хорошая, но -- не для техлида, а для тимлида. Как уже было сказано выше, это разные роли. Это я Вам как бывший техлид говорю :).
В сегодняшнем мире нужно иметь только компьютер и надёжный интернет, для того, чтобы устроиться разработчиком. А находитесь вы при этом в деревне или на Марсе или где-то ещё -- абсолютно неважно.
Ну, наверное, не минификаторы, а бандлеры. Если у вас js-файл начинается с самовызывающейся функции и, соответственно, с открывающей круглой скобки, то при склейке файлов эта скобка окажется где-то в середине кода, и если перед нею нет точки с запятой -- возможны проблемы.
Пожалуйста, не пишите такие комментарии.
У меня на Хабре была небольшая, но честно заработанная карма. Когда я начал критиковать безграмотные тексты (ну достали уже!), мне её моментально слили в ноль.
Видимо, безграмотность в современном мире считается не просто допустимой, но даже достоинством.
Как граммар-наци не могу удержаться и не поправить Вас: слово "говно" пишется через "о".
?
Сначала слегка обалдел, увидев, что Node.js – это фреймворк. Потом обалдел ещё больше, далее прочитав, что Node.js – это ещё и фреймворк для фронтенда.
Эммм...
Хм... А где же Effector?
Уровень
processesавторы методологии уже пару месяцев как отменили.Более 20-ти лет опыта работы, включая обучение???
"непреодолимой"
"потому"
"насчёт"
"немало"
"никого"
"ничего"
Это только один вид ошибок, про запятые и тире тоже в тексте хватает.
К сообществу: простите, накипело – Хабр заполонили полуграмотные статьи, читать больно.
Да, я неправильно понял задачу, наверное из-за того, что мне ни разу в жизни не приходилось объединять два последних коммита и даже сложно представить, зачем это может понадобиться. А вот
amend– регулярно =D.Вроде речь идёт о двух последних коммитах и искать ничего не надо, не?
git log -2– или я опять что-то неправильно понял?git commit --amendЯ обычно описание в таких случаях не правлю, поэтому
git commit --amend --no-editПозволю и себе подушнить: для человека с высшим филологическим образованием три ошибки на такой объём текста – перебор ?.
Но статья интересная, прочитал всю – спасибо! И удачи ?.
Позволю себе поставить под сомнение Ваше утверждение про критическое мышление.
Такой пример: кричащие заголовки (CAPSLOCK, куча восклицательных знаков, "ШОК!" и т.д.) однозначно указывают на то, что читать это не стоит – вряд ли там будет что-то полезное, если внимание привлекается такими дешёвыми и пошлыми методами.
При этом таких заголовков в интернетах куча, т.е., на них кто-то ведётся, и ведётся массово – иначе авторы текстов подобные заголовки бы не использовали.
Это позволяет сделать вывод, что у большого количества людей критическое мышление недостаточно развито.
Т.е. оно есть :).
Это не входит в обязанности форматтеров, это ответственность линтеров.
Форматтеры только добавляют/убирают пробелы и переводы строк, текст программы они не меняют.
Могу предположить за автора, что ему не нравится возникающая в этом случае некоторая дополнительная сложность, например, чтобы извлечь данные по одной сущности из двух таблиц, понадобится дополнительный JOIN.
Поэтому соглашусь, что не стоит использовать "один-к-одному" без веских причин.
Но не соглашусь, что не стоит использовать такую связь вообще никогда, ибо причины всё-таки могут быть.
Ну, тем, кто далёк от проектирования БД, эта терминология незнакома.
Между сущностями (которые в БД превращаются в таблицы) может быть три типа связи (по мощности): один-к-одному, один-ко-многим, многие-ко-многим.
Две таблицы, связанные как "один-к-одному", могут быть объединены в одну без нарушения целостности структуры БД. Такое разделение чаще всего носит технический характер (например, вынести в отдельную таблицу редкоиспользуемые поля большого размера).
На эту тему есть доклад: https://www.youtube.com/watch?v=eVQsWCnSsps
Ну, кроме книг по конкретным технологиям, используемым на проекте сейчас или потенциально, я бы на месте начинающего техлида концентрировался на книгах по качеству кода, таких как:
Роберт Мартин – Чистый код. Создание, анализ и рефакторинг.
Стив Макконнелл – Совершенный код.
Мартин Фаулер - Рефакторинг. Улучшение существующего кода.
Д. Босуэлл, Т. Фаучер – Читаемый код.
и т.д.
И, конечно, ещё книги по инженерным практикам: юнит-тестированию (Ошероув, Мессарош, Хориков – !!!), CI/CD (попадалась книга по Jenkins-у) и т.д.
Делиться знаниями -- это одно, а управлять проектами (Демарко, №6 в Вашем списке) или руководить командой (№№1, 2, 5) -- это совсем другое.
Так что подборка хорошая, но -- не для техлида, а для тимлида. Как уже было сказано выше, это разные роли. Это я Вам как бывший техлид говорю :).
Насколько я понимаю, то же самое можно сделать путём правки файла
workbench.desktop.main.css– это если не хочется ставить ещё одно расширение.В сегодняшнем мире нужно иметь только компьютер и надёжный интернет, для того, чтобы устроиться разработчиком.
А находитесь вы при этом в деревне или на Марсе или где-то ещё -- абсолютно неважно.
Ну, наверное, не минификаторы, а бандлеры.
Если у вас js-файл начинается с самовызывающейся функции и, соответственно, с открывающей круглой скобки, то при склейке файлов эта скобка окажется где-то в середине кода, и если перед нею нет точки с запятой -- возможны проблемы.
Видимо, опечатка: на сайте до 31 декабря.