Да, я неправильно понял задачу, наверное из-за того, что мне ни разу в жизни не приходилось объединять два последних коммита и даже сложно представить, зачем это может понадобиться. А вот amend – регулярно =D.
хеш_коммита_который_ещё_надо_найти
Вроде речь идёт о двух последних коммитах и искать ничего не надо, не? git log -2 – или я опять что-то неправильно понял?
Позволю себе поставить под сомнение Ваше утверждение про критическое мышление.
Такой пример: кричащие заголовки (CAPSLOCK, куча восклицательных знаков, "ШОК!" и т.д.) однозначно указывают на то, что читать это не стоит – вряд ли там будет что-то полезное, если внимание привлекается такими дешёвыми и пошлыми методами.
При этом таких заголовков в интернетах куча, т.е., на них кто-то ведётся, и ведётся массово – иначе авторы текстов подобные заголовки бы не использовали.
Это позволяет сделать вывод, что у большого количества людей критическое мышление недостаточно развито.
Могу предположить за автора, что ему не нравится возникающая в этом случае некоторая дополнительная сложность, например, чтобы извлечь данные по одной сущности из двух таблиц, понадобится дополнительный JOIN.
Поэтому соглашусь, что не стоит использовать "один-к-одному" без веских причин.
Но не соглашусь, что не стоит использовать такую связь вообще никогда, ибо причины всё-таки могут быть.
Ну, тем, кто далёк от проектирования БД, эта терминология незнакома.
Между сущностями (которые в БД превращаются в таблицы) может быть три типа связи (по мощности): один-к-одному, один-ко-многим, многие-ко-многим.
Две таблицы, связанные как "один-к-одному", могут быть объединены в одну без нарушения целостности структуры БД. Такое разделение чаще всего носит технический характер (например, вынести в отдельную таблицу редкоиспользуемые поля большого размера).
Ну, кроме книг по конкретным технологиям, используемым на проекте сейчас или потенциально, я бы на месте начинающего техлида концентрировался на книгах по качеству кода, таких как:
Роберт Мартин – Чистый код. Создание, анализ и рефакторинг.
Стив Макконнелл – Совершенный код.
Мартин Фаулер - Рефакторинг. Улучшение существующего кода.
Д. Босуэлл, Т. Фаучер – Читаемый код.
и т.д.
И, конечно, ещё книги по инженерным практикам: юнит-тестированию (Ошероув, Мессарош, Хориков – !!!), CI/CD (попадалась книга по Jenkins-у) и т.д.
Делиться знаниями -- это одно, а управлять проектами (Демарко, №6 в Вашем списке) или руководить командой (№№1, 2, 5) -- это совсем другое. Так что подборка хорошая, но -- не для техлида, а для тимлида. Как уже было сказано выше, это разные роли. Это я Вам как бывший техлид говорю :).
В сегодняшнем мире нужно иметь только компьютер и надёжный интернет, для того, чтобы устроиться разработчиком. А находитесь вы при этом в деревне или на Марсе или где-то ещё -- абсолютно неважно.
Ну, наверное, не минификаторы, а бандлеры. Если у вас js-файл начинается с самовызывающейся функции и, соответственно, с открывающей круглой скобки, то при склейке файлов эта скобка окажется где-то в середине кода, и если перед нею нет точки с запятой -- возможны проблемы.
Производительный код тоже может быть качественным, если его писать "по уму" и снабжать комментариями по мере необходимости.
Вот как раз качественный код комментариев не требует, их необходимость указывает на то, что код сам по себе нечитабельный, приходится подпорки ставить в виде комментариев.
Производительный код может быть качественным, но это большая редкость. Чаще всего для того, чтобы сделать код производительным, приходится сознательно ухудшать такие его характеристики, как читабельность, расширяемость, сопровождаемость и т.д., в т.ч. избегать использования шаблонов и идти на сознательное нарушение принципов (SOLID, GRASP, KISS и т.д.).
А наворачиванием шаблонов качество можно только ухудшить.
Конечно, можно. В кривых руках даже при отличном инструменте результат будет кривой. И точно так же качество можно ухудшить, всячески избегая использования шаблонов. Как применение, так и неприменение чего бы то ни было требует осознанности :).
Тогда эти рекомендации не для Вас :) Качественный код (читабельный, сопровождаемый и т.д.) и производительный код -- понятия чаще всего взаимоисключающие. Если Вы пишите код для встраиваемых систем и экономите байты -- о каком полиморфизме может идти речь?
Да, я неправильно понял задачу, наверное из-за того, что мне ни разу в жизни не приходилось объединять два последних коммита и даже сложно представить, зачем это может понадобиться. А вот
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 декабря.
Когда я кодю, в наушниках всегда играет медленный блюз.
КДПВ: после этого фильма я всей душой полюбил блюзы... Крайне рекомендую к просмотру!
Простите, не могу удержаться ??????
Хм, я думал, что нажимающие кнопки на процессоре уже все давно естественным образом вымерли. Ан нет! :D
Вот как раз качественный код комментариев не требует, их необходимость указывает на то, что код сам по себе нечитабельный, приходится подпорки ставить в виде комментариев.
Производительный код может быть качественным, но это большая редкость. Чаще всего для того, чтобы сделать код производительным, приходится сознательно ухудшать такие его характеристики, как читабельность, расширяемость, сопровождаемость и т.д., в т.ч. избегать использования шаблонов и идти на сознательное нарушение принципов (SOLID, GRASP, KISS и т.д.).
Конечно, можно. В кривых руках даже при отличном инструменте результат будет кривой.
И точно так же качество можно ухудшить, всячески избегая использования шаблонов.
Как применение, так и неприменение чего бы то ни было требует осознанности :).
Тогда эти рекомендации не для Вас :)
Качественный код (читабельный, сопровождаемый и т.д.) и производительный код -- понятия чаще всего взаимоисключающие. Если Вы пишите код для встраиваемых систем и экономите байты -- о каком полиморфизме может идти речь?