#Education #Translation
Базовая база IT: интерпретация vs компиляция
Давайте немного углубимся в стародавние времена IT, когда деды программисты не дрались на форумах, а зарубались на тему трансляции кода. Этот вопрос до сих пор вызывает жаркие споры и является настоящим полем битвы для тех, кто любит посраться на тему производительности языков и их особенностей. Одним из таких легендарных срачей был момент, когда Рихтер заявлял, что в некоторых случаях C# оказывается производительнее C++. Давайте попробуем в этом разобраться.
Трансляция: с чего всё начинается
Во главе всего стоит трансляция — это процесс, который переводит исходный код с понятного человеку языка на язык машины. Комплюхтеры у нас — существа простые, понимают только последовательность единичек и нулей, поэтому наша задача — перевести понятный для программиста код в машинные коды, которые выполнит процессор. В реальности трансляция программы происходит с участием промежуточного языка — обычно это ассемблер, который уже потом превращается в машинный код.
Интерпретация
В те времена, когда программисты тыкали перфокарты, первый метод трансляции был именно интерпретацией. По сути, каждая перфокарта содержала одну строку кода, которую комплюхтер тут же выполнял. Сейчас процесс интерпретации немного изменился, но суть осталась: программа на интерпретируемом языке (например, JavaScript или Python) исполняется построчно, программа-интерпретатор выполняет её "на лету", без создания отдельного исполняемого файла.
Плюсы и минусы интерпретации:
Компиляция
В противовес интерпретации возникла компиляция. Перфокарты никуда не делись, но код стал мощнее и структурированнее. Первым компилируемым языком был Fortran — тогда программисты уже использовали операторы ветвления и циклы, а не просто простейшие команды. Процесс компиляции позволял заранее прочитать весь код программы, проанализировать его, а затем превратить в исполнимый файл — так называемый бинарник.
Плюсы и минусы компиляции:
JIT-компиляция
Сегодня мы часто сталкиваемся с так называемой JIT-компиляцией (Just-In-Time). Этот подход комбинирует оба метода. Код программы компилируется в промежуточный байт-код, который затем интерпретируется на виртуальной машине (например, JVM для Java или CLR для C#). Это позволяет сохранять гибкость интерпретируемого кода, но при этом получать производительность, близкую к компилируемым языкам.
Плюсы JIT-компиляции:
Пример языков с JIT-компиляцией: C#, Java, и даже JavaScript и Python, у которых под капотом сложные процессы компиляции в промежуточный байт-код.
Базовая база IT: интерпретация vs компиляция
Давайте немного углубимся в стародавние времена IT, когда деды программисты не дрались на форумах, а зарубались на тему трансляции кода. Этот вопрос до сих пор вызывает жаркие споры и является настоящим полем битвы для тех, кто любит посраться на тему производительности языков и их особенностей. Одним из таких легендарных срачей был момент, когда Рихтер заявлял, что в некоторых случаях C# оказывается производительнее C++. Давайте попробуем в этом разобраться.
Трансляция: с чего всё начинается
Во главе всего стоит трансляция — это процесс, который переводит исходный код с понятного человеку языка на язык машины. Комплюхтеры у нас — существа простые, понимают только последовательность единичек и нулей, поэтому наша задача — перевести понятный для программиста код в машинные коды, которые выполнит процессор. В реальности трансляция программы происходит с участием промежуточного языка — обычно это ассемблер, который уже потом превращается в машинный код.
Интерпретация
В те времена, когда программисты тыкали перфокарты, первый метод трансляции был именно интерпретацией. По сути, каждая перфокарта содержала одну строку кода, которую комплюхтер тут же выполнял. Сейчас процесс интерпретации немного изменился, но суть осталась: программа на интерпретируемом языке (например, JavaScript или Python) исполняется построчно, программа-интерпретатор выполняет её "на лету", без создания отдельного исполняемого файла.
Плюсы и минусы интерпретации:
1. Программы легче переносить между разными архитектурами, так как ответственность за исполнение берёт на себя интерпретатор.
2. Интерпретируемые программы легче поддаются изменениям "на лету", так как нет необходимости их компилировать.
3. Производительность ниже, потому что программа анализируется и выполняется построчно.
Ошибки в коде обнаруживаются только в момент выполнения, что может привести к неожиданным багам и весёлым приключениям с дебагом.
Компиляция
В противовес интерпретации возникла компиляция. Перфокарты никуда не делись, но код стал мощнее и структурированнее. Первым компилируемым языком был Fortran — тогда программисты уже использовали операторы ветвления и циклы, а не просто простейшие команды. Процесс компиляции позволял заранее прочитать весь код программы, проанализировать его, а затем превратить в исполнимый файл — так называемый бинарник.
Плюсы и минусы компиляции:
1. Производительность. Код компилируется для конкретной архитектуры, что даёт максимальную эффективность при исполнении.
2. Валидация ошибок. Компилятор заранее проверяет код, что даёт возможность отловить большинство ошибок до исполнения.
3. Код привязан к архитектуре — скомпилированная программа не сможет работать на другом типе процессора без дополнительной компиляции.
4. Компиляция занимает время, что делает процесс разработки менее гибким по сравнению с интерпретацией.
JIT-компиляция
Сегодня мы часто сталкиваемся с так называемой JIT-компиляцией (Just-In-Time). Этот подход комбинирует оба метода. Код программы компилируется в промежуточный байт-код, который затем интерпретируется на виртуальной машине (например, JVM для Java или CLR для C#). Это позволяет сохранять гибкость интерпретируемого кода, но при этом получать производительность, близкую к компилируемым языкам.
Плюсы JIT-компиляции:
1. Код можно использовать на разных архитектурах благодаря виртуальной машине, что делает программы кросс-платформенными.
2. После первого выполнения байт-код кэшируется и может использоваться повторно без повторной компиляции.
Пример языков с JIT-компиляцией: C#, Java, и даже JavaScript и Python, у которых под капотом сложные процессы компиляции в промежуточный байт-код.
#Translation
Почему всё это важно
Так как все эти процессы взаимодействуют на разных уровнях, дискуссии о том, какой язык производительнее, часто основаны на недопонимании того, как эти процессы работают на самом деле. Например, сравнивать C# и C++ в чистом виде — это немного абсурдно, потому что на высоком уровне и там, и там в дело вступает JIT, кеширование, оптимизация на уровне виртуальной машины и ещё куча других факторов. Но это не мешает IT-шникам устраивать локальные войны на эту тему.
Так что теперь вы готовы участвовать в высокоинтеллектуальных дебатах и отстаивать свою правоту, зная что такое интерпретация, компиляция и JIT!
Почему всё это важно
Так как все эти процессы взаимодействуют на разных уровнях, дискуссии о том, какой язык производительнее, часто основаны на недопонимании того, как эти процессы работают на самом деле. Например, сравнивать C# и C++ в чистом виде — это немного абсурдно, потому что на высоком уровне и там, и там в дело вступает JIT, кеширование, оптимизация на уровне виртуальной машины и ещё куча других факторов. Но это не мешает IT-шникам устраивать локальные войны на эту тему.
❤2
#Education #Paradigms
Парадигмы написания кода:
Итак, тема парадигм программирования — это одна из тех, от которой, как говорится, даже видавшие виды айтишники могут спотыкнуться. Формальные определения часто заставляют мозг вскипеть, а преподаватели умудряются подавать материал так, что и сам черт не разберет. Но, давайте посмотрим на эту тему проще и с юмором.
Парадигма программирования — это просто набор правил, которые мы используем для написания кода. Это так скажем "философия" кода: как мы будем его строить и как наш комплюхтер это переварит. Мне, если честно, само слово "парадигма" не очень нравится и я бы с радостью заменил бы его на слово "модель", но тогда у вас потеряется мистический смысл.
Императивное программирование
Императивное программирование — это то, с чего начинали деды, и оно является основой для всех других парадигм. Тут всё просто: ты даешь машине чёткие инструкции, шаг за шагом. Написал алгоритм — машина исполнила. Это как давать указания, которые нужно строго выполнять.
Яркий пример — это тот же Assembler. Ты даешь машине прямые команды и говоришь, в каком регистре что должно быть. Управляющих конструкций особо нет, но зато есть go to (или jump), с помощью которой можно телепортироваться по коду. Это адовая хрень для любого программиста, потому что легко запутаться, особенно если код становится большим.
Структурное программирование
Всё изменилось, когда Эдсгер Дейкстра решил, что с этой ахинеей пора что-то делать. Он настолько устал от бардака с go to, что не зассал предложил разбивать код на логические части с помощью подпрограмм, циклов и управляющих конструкций. Так и появилась структурная парадигма, которая дала возможность разбивать код на более понятные блоки.
Теперь кодеры могли использовать подпрограммы и передавать управление туда, где это нужно, а не прыгать по коду, как блоха по ковру. Яркие примеры языков, которые поддерживают эту парадигму — это "C", Pascal и Basic.
"C" стал настоящим прорывом, потому что его использовали для более сложных систем, чем просто написание одной большой программы.
Объектно-Ориентированное Программирование (ООП)
Когда программисты сидели и кодили на структурных языках, они заметили интересный эффект: если переменные из подпрограмм не убирать сразу из памяти, то их можно использовать и в других подпрограммах. Так случайно и родилась ООП-парадигма.
Смысл ООП в том, что программирование теперь вращается вокруг объектов и классов. Объекты — это конкретные экземпляры классов, которые могут иметь свои данные и методы. А классы можно рассматривать как чертежи для создания объектов.
ООП дала нам такие плюшки как:
Благодаря этому ООП взлетело на всех фронтах, и такие языки как Java, C++, и более новые, такие как Python, активно используют эту парадигму.
Комбинирование парадигм
Что интересно, современные языки программирования редко придерживаются одной единственной парадигмы. Они часто сочетают несколько подходов, чтобы дать больше гибкости разработчикам. Например:
Парадигмы написания кода:
Итак, тема парадигм программирования — это одна из тех, от которой, как говорится, даже видавшие виды айтишники могут спотыкнуться. Формальные определения часто заставляют мозг вскипеть, а преподаватели умудряются подавать материал так, что и сам черт не разберет. Но, давайте посмотрим на эту тему проще и с юмором.
Парадигма программирования — это просто набор правил, которые мы используем для написания кода. Это так скажем "философия" кода: как мы будем его строить и как наш комплюхтер это переварит. Мне, если честно, само слово "парадигма" не очень нравится и я бы с радостью заменил бы его на слово "модель", но тогда у вас потеряется мистический смысл.
Императивное программирование
Императивное программирование — это то, с чего начинали деды, и оно является основой для всех других парадигм. Тут всё просто: ты даешь машине чёткие инструкции, шаг за шагом. Написал алгоритм — машина исполнила. Это как давать указания, которые нужно строго выполнять.
Яркий пример — это тот же Assembler. Ты даешь машине прямые команды и говоришь, в каком регистре что должно быть. Управляющих конструкций особо нет, но зато есть go to (или jump), с помощью которой можно телепортироваться по коду. Это адовая хрень для любого программиста, потому что легко запутаться, особенно если код становится большим.
Структурное программирование
Всё изменилось, когда Эдсгер Дейкстра решил, что с этой ахинеей пора что-то делать. Он настолько устал от бардака с go to, что не зассал предложил разбивать код на логические части с помощью подпрограмм, циклов и управляющих конструкций. Так и появилась структурная парадигма, которая дала возможность разбивать код на более понятные блоки.
Теперь кодеры могли использовать подпрограммы и передавать управление туда, где это нужно, а не прыгать по коду, как блоха по ковру. Яркие примеры языков, которые поддерживают эту парадигму — это "C", Pascal и Basic.
"C" стал настоящим прорывом, потому что его использовали для более сложных систем, чем просто написание одной большой программы.
Объектно-Ориентированное Программирование (ООП)
Когда программисты сидели и кодили на структурных языках, они заметили интересный эффект: если переменные из подпрограмм не убирать сразу из памяти, то их можно использовать и в других подпрограммах. Так случайно и родилась ООП-парадигма.
Смысл ООП в том, что программирование теперь вращается вокруг объектов и классов. Объекты — это конкретные экземпляры классов, которые могут иметь свои данные и методы. А классы можно рассматривать как чертежи для создания объектов.
ООП дала нам такие плюшки как:
1. Инкапсуляция — скрытие деталей реализации от других частей программы.
2. Наследование — возможность создавать новые классы на основе существующих.
3. Полиморфизм — это когда один и тот же метод может вести себя по-разному в зависимости от того, какой объект его вызывает.
Благодаря этому ООП взлетело на всех фронтах, и такие языки как Java, C++, и более новые, такие как Python, активно используют эту парадигму.
Комбинирование парадигм
Что интересно, современные языки программирования редко придерживаются одной единственной парадигмы. Они часто сочетают несколько подходов, чтобы дать больше гибкости разработчикам. Например:
Java — это мощный объектно-ориентированный язык, но он также поддерживает элементы императивного программирования.
Python — тут можно писать как в стиле ООП, так и в процедурном стиле, что даёт свободу выбора для разработчика.
PHP — до версии 4 был чисто процедурным, но позже медленно, но уверенно переключился в сторону ООП. Тем не менее, никто не мешает писать в нём и процедурный код, что и порождает смесь стилей в проектах.
#Education #Paradigms
Другие интересные парадигмы
Есть и другие парадигмы, которые тоже достойны упоминания:
Функциональное программирование — его основная идея в том, что всё представляется в виде функций. Функции могут передаваться как параметры другим функциям, а также возвращать другие функции. Этот стиль активно используют в языках вроде Haskell или даже в тех же JavaScript и Python, где поддерживаются функциональные элементы.
Декларативное программирование — тут ты не пишешь, как выполнить задачу, а говоришь, что нужно сделать. Пример: SQL — ты просто описываешь, какие данные тебе нужны, а база данных уже сама решает, как их получить.
Парадигмы программирования — это разные способы думать о написании кода. Они помогают программистам выбрать подход, который лучше всего решает задачу. Важно понимать, что многие современные языки комбинируют разные парадигмы, давая возможность выбирать то, что будет удобнее всего.
Другие интересные парадигмы
Есть и другие парадигмы, которые тоже достойны упоминания:
Функциональное программирование — его основная идея в том, что всё представляется в виде функций. Функции могут передаваться как параметры другим функциям, а также возвращать другие функции. Этот стиль активно используют в языках вроде Haskell или даже в тех же JavaScript и Python, где поддерживаются функциональные элементы.
Декларативное программирование — тут ты не пишешь, как выполнить задачу, а говоришь, что нужно сделать. Пример: SQL — ты просто описываешь, какие данные тебе нужны, а база данных уже сама решает, как их получить.
Парадигмы программирования — это разные способы думать о написании кода. Они помогают программистам выбрать подход, который лучше всего решает задачу. Важно понимать, что многие современные языки комбинируют разные парадигмы, давая возможность выбирать то, что будет удобнее всего.
🔥1
#JavaScript
Я чувствую, что в моих словах горит священный огонь защитника JavaScript, и, честно говоря, сложно не согласиться с собой. Весь этот старперский снобизм по отношению к JS уже давно отдает плесенью двухтысячных офисов с Windows XP и IE6. Давайте сразу к делу — JavaScript это гораздо больше, чем просто анимации и подсветка кнопочек.
1. Инфраструктура — мирового уровня
Первое, что нужно выдвинуть в защиту JavaScript, — это его невероятно развитая экосистема. npm — крупнейший репозиторий пакетов в мире. Хочешь фреймворк для чего угодно? Есть React, Vue, Angular. Хочешь сервер на JavaScript? Вот тебе Node.js с асинхронной магией, которая заставляет любой backend пахать, как швейцарские часы.
Плюс, весь набор инструментов разработки — Webpack, Rollup, Parcel и десятки других сборщиков, которые позволяют поддерживать этот язык и адаптировать его под любую задачу. Babel и TypeScript делают то, что критики из "галерных офисов" вообще не готовы принять: они превращают JavaScript в "чемпионский комбайн", который может решать задачи как на фронте, так и на бэке с невероятной гибкостью.
2. Асинхронность — прямо из коробки
JavaScript буквально изначально асинхронен, и это один из его самых сладких плюсов. Промисы, async/await — это магия, которая избавляет тебя от заморочек с потоками, блокировками и прочим адом, который в других языках делает разработку асинхронных приложений настоящей головной болью. Вы не мучаетесь с многопоточностью как в Java или C#, вам не нужно следить за сотнями нюансов потокобезопасности. JavaScript делает асинхронное программирование естественным.
И не забывайте про серверный JS — тот же Node.js вообще строится на этой философии. Никакого забивания процессора, никакой необходимости в десяти серверах, чтобы обслуживать простую задачу — всё работает эффективно и быстро.
3. Динамическая типизация — свобода самовыражения
Вот тут начинается самое сладкое — динамическая типизация. Её любят хейтить те, кто застрял в статически типизированных языках вроде Java или C++, где ты должен каждый раз танцевать с бубном над типами и полиморфизмом. Но в JavaScript ты можешь творить без тормозов.
Да, кто-то скажет: "Но контроль над типами же!" — ну да, как же без старой песни про типизацию. Но это в основном страх тех, кто привык к строгости компилятора. Когда ты работаешь в JavaScript, ты получаешь свободу. Хочешь быстро закидать логику на коленке? Пожалуйста. Надо динамически подогнать структуры данных? Это не проблема. Не надо перегружать методы, не надо жонглировать с дженериками и шаблонами, ты просто пишешь код и получаешь результат.
4. Функциональные фичи — где надо и как надо
JavaScript не только про императивщину, он прекрасно поддерживает функциональный стиль. И это не просто поддержка, а реальные фичи, которые делают жизнь легче: map, reduce, filter — с такими функциями вы можете манипулировать данными как бог. Вы можете создавать чистые функции, использовать замыкания, строить цепочки вызовов, как будто играешь в сложную игру с Lego.
При этом тебе не обязательно уходить в глубокий функциональный подход как в Haskell. В JavaScript всё работает гибко: хочешь применять функциональные концепции — пожалуйста, не хочешь — можешь писать более императивный код. Эдакий гибрид, который подстроится под твои задачи.
5. Универсальность и популярность
А теперь самое главное: JavaScript сегодня — это язык номер один по популярности и применению. Это язык, который правит на фронтенде, захватывает бэкенд через Node.js и вообще проникает повсюду. Ты пишешь один язык и можешь строить полноценные веб-приложения с фронта до бэка. Это мощь, это гибкость, и это невозможно не признать.
Я чувствую, что в моих словах горит священный огонь защитника JavaScript, и, честно говоря, сложно не согласиться с собой. Весь этот старперский снобизм по отношению к JS уже давно отдает плесенью двухтысячных офисов с Windows XP и IE6. Давайте сразу к делу — JavaScript это гораздо больше, чем просто анимации и подсветка кнопочек.
1. Инфраструктура — мирового уровня
Первое, что нужно выдвинуть в защиту JavaScript, — это его невероятно развитая экосистема. npm — крупнейший репозиторий пакетов в мире. Хочешь фреймворк для чего угодно? Есть React, Vue, Angular. Хочешь сервер на JavaScript? Вот тебе Node.js с асинхронной магией, которая заставляет любой backend пахать, как швейцарские часы.
Плюс, весь набор инструментов разработки — Webpack, Rollup, Parcel и десятки других сборщиков, которые позволяют поддерживать этот язык и адаптировать его под любую задачу. Babel и TypeScript делают то, что критики из "галерных офисов" вообще не готовы принять: они превращают JavaScript в "чемпионский комбайн", который может решать задачи как на фронте, так и на бэке с невероятной гибкостью.
2. Асинхронность — прямо из коробки
JavaScript буквально изначально асинхронен, и это один из его самых сладких плюсов. Промисы, async/await — это магия, которая избавляет тебя от заморочек с потоками, блокировками и прочим адом, который в других языках делает разработку асинхронных приложений настоящей головной болью. Вы не мучаетесь с многопоточностью как в Java или C#, вам не нужно следить за сотнями нюансов потокобезопасности. JavaScript делает асинхронное программирование естественным.
И не забывайте про серверный JS — тот же Node.js вообще строится на этой философии. Никакого забивания процессора, никакой необходимости в десяти серверах, чтобы обслуживать простую задачу — всё работает эффективно и быстро.
3. Динамическая типизация — свобода самовыражения
Вот тут начинается самое сладкое — динамическая типизация. Её любят хейтить те, кто застрял в статически типизированных языках вроде Java или C++, где ты должен каждый раз танцевать с бубном над типами и полиморфизмом. Но в JavaScript ты можешь творить без тормозов.
Да, кто-то скажет: "Но контроль над типами же!" — ну да, как же без старой песни про типизацию. Но это в основном страх тех, кто привык к строгости компилятора. Когда ты работаешь в JavaScript, ты получаешь свободу. Хочешь быстро закидать логику на коленке? Пожалуйста. Надо динамически подогнать структуры данных? Это не проблема. Не надо перегружать методы, не надо жонглировать с дженериками и шаблонами, ты просто пишешь код и получаешь результат.
4. Функциональные фичи — где надо и как надо
JavaScript не только про императивщину, он прекрасно поддерживает функциональный стиль. И это не просто поддержка, а реальные фичи, которые делают жизнь легче: map, reduce, filter — с такими функциями вы можете манипулировать данными как бог. Вы можете создавать чистые функции, использовать замыкания, строить цепочки вызовов, как будто играешь в сложную игру с Lego.
При этом тебе не обязательно уходить в глубокий функциональный подход как в Haskell. В JavaScript всё работает гибко: хочешь применять функциональные концепции — пожалуйста, не хочешь — можешь писать более императивный код. Эдакий гибрид, который подстроится под твои задачи.
5. Универсальность и популярность
А теперь самое главное: JavaScript сегодня — это язык номер один по популярности и применению. Это язык, который правит на фронтенде, захватывает бэкенд через Node.js и вообще проникает повсюду. Ты пишешь один язык и можешь строить полноценные веб-приложения с фронта до бэка. Это мощь, это гибкость, и это невозможно не признать.
#JavaScript
Критика JavaScript как "недоязыка" звучит особенно смешно на фоне его повсеместного использования в крупных корпорациях, стартапах и высокотехнологичных проектах. Этот язык, который начали с анимаций для кнопочек, сейчас способен строить сложные распределённые системы, и это уже доказано множеством успешных проектов.
JS — это про гибкость, свободу и реальную мощь, которой можно воспользоваться прямо сейчас. Да, он не идеален. Да, у него есть свои особенности и косяки (какой язык их не имеет?). Но если тебе нужно разрабатывать современные приложения, писать один язык для всего стека, и при этом не тратить годы на обучение каждому фреймворку — JavaScript твой выбор.
Критика JavaScript как "недоязыка" звучит особенно смешно на фоне его повсеместного использования в крупных корпорациях, стартапах и высокотехнологичных проектах. Этот язык, который начали с анимаций для кнопочек, сейчас способен строить сложные распределённые системы, и это уже доказано множеством успешных проектов.
Ну и что на это ответить тем, кто до сих пор считает, что JavaScript — это "детский" язык? Да они просто отстали от времени. Те, кто сидят в своих галерах и жалуются на невозможность понять динамическую типизацию или асинхронность, видимо, просто не хотят выходить из своей зоны комфорта.
JS — это про гибкость, свободу и реальную мощь, которой можно воспользоваться прямо сейчас. Да, он не идеален. Да, у него есть свои особенности и косяки (какой язык их не имеет?). Но если тебе нужно разрабатывать современные приложения, писать один язык для всего стека, и при этом не тратить годы на обучение каждому фреймворку — JavaScript твой выбор.
Ну, а те, кто продолжают хейтить, могут продолжать сидеть в своих статически типизированных замках. Мы будем писать и развиваться, потому что JavaScript — это про будущее.
🔥1
#Linux #OS
Почему Питер на Linux — это не всегда сила, а иногда просто комедия
Давайте разберемся, почему в мире разработки так важна унификация, и почему "Питер", который сидит на своей убунте, может быть не таким уж крутым, как ему кажется.
Работая с тремя операционными системами — Ubuntu, Windows и macOS — я пришел к выводу, что нанимают разработчиков не для того, чтобы они настраивали свои убунты под себя, а чтобы решали реальные проблемы бизнеса. В большинстве случаев нам дают Windows или macOS ноуты с уже частично настроенными инструментами, а что-то устанавливаем под конкретный проект. И, о чудо, у компаний есть гайды, как все это делать!
Зачем это нужно? Чтобы у всех в команде было "как у всех". Понимаете? Чтобы баги воспроизводились одинаково. А не так, чтобы у "Питера" на Linux что-то отвалилось, а остальные на Windows сидят и не могут воспроизвести баг. Это же как в комедии: "У кого-то сломался велосипед, а остальные на машинах — и что теперь делать?"
Но вот "Питер" — настоящий программист, да? Он же на Linux сидит! Мощь! 😂😂😂 В его глазах это как медаль за отвагу. Но давайте будем честными: сколько комбинаций клавиш в vi, vim или neovim нужно запомнить, чтобы просто редактировать текст? 999+? Зачем? Чтобы потом сидеть и настраивать свой vim так, чтобы он хоть немного напоминал JetBrains IDE?
Нам дали унифицированный способ взаимодействия с текстом — JetBrains IDE, курсор, мышь и клавиатура. Но некоторые считают, что это для слабаков. 😂😂😂
В конце концов, не важно, насколько быстро ты печатаешь, если думать получается медленно. Это математика, друзья. Так что, может, стоит оставить "Питера" с его Linux и вернуться к реальным задачам?
Ведь в мире разработки главное — это не операционная система, а результат. А если "Питер" не может воспроизвести баг, то, возможно, ему стоит задуматься, кто на самом деле "слабак". 😄
Почему Питер на Linux — это не всегда сила, а иногда просто комедия
Давайте разберемся, почему в мире разработки так важна унификация, и почему "Питер", который сидит на своей убунте, может быть не таким уж крутым, как ему кажется.
Работая с тремя операционными системами — Ubuntu, Windows и macOS — я пришел к выводу, что нанимают разработчиков не для того, чтобы они настраивали свои убунты под себя, а чтобы решали реальные проблемы бизнеса. В большинстве случаев нам дают Windows или macOS ноуты с уже частично настроенными инструментами, а что-то устанавливаем под конкретный проект. И, о чудо, у компаний есть гайды, как все это делать!
Зачем это нужно? Чтобы у всех в команде было "как у всех". Понимаете? Чтобы баги воспроизводились одинаково. А не так, чтобы у "Питера" на Linux что-то отвалилось, а остальные на Windows сидят и не могут воспроизвести баг. Это же как в комедии: "У кого-то сломался велосипед, а остальные на машинах — и что теперь делать?"
Но вот "Питер" — настоящий программист, да? Он же на Linux сидит! Мощь! 😂😂😂 В его глазах это как медаль за отвагу. Но давайте будем честными: сколько комбинаций клавиш в vi, vim или neovim нужно запомнить, чтобы просто редактировать текст? 999+? Зачем? Чтобы потом сидеть и настраивать свой vim так, чтобы он хоть немного напоминал JetBrains IDE?
Нам дали унифицированный способ взаимодействия с текстом — JetBrains IDE, курсор, мышь и клавиатура. Но некоторые считают, что это для слабаков. 😂😂😂
В конце концов, не важно, насколько быстро ты печатаешь, если думать получается медленно. Это математика, друзья. Так что, может, стоит оставить "Питера" с его Linux и вернуться к реальным задачам?
Ведь в мире разработки главное — это не операционная система, а результат. А если "Питер" не может воспроизвести баг, то, возможно, ему стоит задуматься, кто на самом деле "слабак". 😄
🔥1
#AI
Да, я тут сайд-проект пишу с помощью JetBrains AI. Знаете, это как общаться с умным другом, который иногда забывает, что у него есть мозг. Главное — писать явно и максимально точно то, что хочешь. А он, как будто на стероидах, генерирует по 100 строк кода, как будто у него есть личный ассистент с дипломом.
Но вот беда: многие люди не умеют с ним общаться. Слышал, как кто-то восклицает: "Ваш ИИ тупой, неправильно отвечает на вопрос!" А потом смотришь на их запрос и думаешь: "Серьезно? 'Сделай программу скачивания фильмов' — это всё, что ты можешь придумать?" Это как если бы ты пришёл в ресторан и заказал "еду", а потом жаловался, что тебе принесли что-то странное.
Иногда ИИ действительно выдает нелогичные вещи, но стоит просто сказать: "Эй, не делай так!" — и он, как послушный щенок, исправляется.
Почему не очень просить его написать код? Да потому что это всё равно что просить соседа, который не умеет готовить, сделать тебе ужин. Ты же не будешь удивляться, если он подаст тебе макароны с вареньем! Но, если честно, я прошу и меня это устраивает. Да, иногда приходится его поправлять, как маленького ребёнка, который только учится ходить. Но это часть процесса, и, в конце концов, у меня мало претензий к последней платной модели GPT-4. Она, похоже, действительно "ушла далеко" — как будто на курсы повышения квалификации для ИИ.
Так что, ребята, учитесь формулировать свои запросы! И помните: ИИ — это не волшебная палочка, а скорее ваш умный, но немного рассеянный друг, который иногда нуждается в подсказках.
Да, я тут сайд-проект пишу с помощью JetBrains AI. Знаете, это как общаться с умным другом, который иногда забывает, что у него есть мозг. Главное — писать явно и максимально точно то, что хочешь. А он, как будто на стероидах, генерирует по 100 строк кода, как будто у него есть личный ассистент с дипломом.
Но вот беда: многие люди не умеют с ним общаться. Слышал, как кто-то восклицает: "Ваш ИИ тупой, неправильно отвечает на вопрос!" А потом смотришь на их запрос и думаешь: "Серьезно? 'Сделай программу скачивания фильмов' — это всё, что ты можешь придумать?" Это как если бы ты пришёл в ресторан и заказал "еду", а потом жаловался, что тебе принесли что-то странное.
Иногда ИИ действительно выдает нелогичные вещи, но стоит просто сказать: "Эй, не делай так!" — и он, как послушный щенок, исправляется.
Почему не очень просить его написать код? Да потому что это всё равно что просить соседа, который не умеет готовить, сделать тебе ужин. Ты же не будешь удивляться, если он подаст тебе макароны с вареньем! Но, если честно, я прошу и меня это устраивает. Да, иногда приходится его поправлять, как маленького ребёнка, который только учится ходить. Но это часть процесса, и, в конце концов, у меня мало претензий к последней платной модели GPT-4. Она, похоже, действительно "ушла далеко" — как будто на курсы повышения квалификации для ИИ.
Так что, ребята, учитесь формулировать свои запросы! И помните: ИИ — это не волшебная палочка, а скорее ваш умный, но немного рассеянный друг, который иногда нуждается в подсказках.
🔥2👍1
#Programming
Все языки программирования — говно
Аксиома Эксобара, касающаяся языков программирования, долго не давала мне покоя, и, как объективный и беспристрастный IT-специалист, могу смело заявить: все языки программирования — говно.
Каждый из этих ваших "наборов инструкций и операторов" полон недостатков, и начнём мы, конечно, с JavaScript:
Как бы мы ни любили JS, нужно признать: этот язык — далеко не идеал. У него отсутствует четкая структура, а стандарты его столь же туманны, как утренний кофе после бессонной ночи. Прототипное ООП? Да это же настоящий музей костылей! Использование его для backend программирования — вообще анекдот. Но при всём этом, несмотря на несуразные корни и проблемы с ООП, JavaScript — это настоящий "швейцарский нож". Он проникает везде, и его универсальность — его главный козырь.
PHP
С PHP все немного иначе. Это словно друг из детства, который хоть и не самый умный, но всегда готов прийти на помощь. В нём есть всё, чтобы быстро собрать сайт "на коленке". Хотя давайте будем честными: чем глубже вы погружаетесь в проекты на PHP, тем больше встречаете кривого и непонятного кода от старых версий.
Python
Пользователи Python с их бесконечными спорами о табах и пробелах заслуживают отдельного внимания. Без фигурных скобок писать код как-то даже странно. И да, сообщество активно обсуждает, как правильно делать отступы, вместо того чтобы решать насущные проблемы производительности или многопоточности. Python хорош для скриптов и автоматизации, но как только речь заходит о более сложных проектах, вы сталкиваетесь с множеством компромиссов и костылей.
Java
Java — это как старая машина, которая по-прежнему работает, но требует слишком много ресурсов. 3 миллиарда устройств? Да, возможно. Но все знают, что Java медленно движется на старом коде и зачастую является излишне тяжёлой. Её прожорливость и неповоротливость — это испытание для любого разработчика. Каждый раз, когда вы запускаете Android Studio, вам хочется выключить обогрев в комнате — так сильно она греет наше очко.
C#
C# — это язык, который пытается быть универсальным, но порой в этом желании вы буквально тонете в типах и абстракциях. Вместо решения прикладных задач вы увязаете в типах, наследовании и бесконечных абстракциях. Это словно лабиринт, в котором, чтобы решить простую задачу, приходится блуждать, параллельно слушая советы всевозможных "гуру".
Итак, не языки определяют успех, а инструменты и фреймворки. Языки — это лишь способ подключения к действительно полезным инструментам, будь то библиотеки или платформы. Именно они делают язык популярным или нет. Завтра может появиться новый фреймворк или инструмент, который изменит правила игры, и язык, который вчера считался устаревшим, внезапно окажется в центре внимания.
Все языки программирования — говно
Аксиома Эксобара, касающаяся языков программирования, долго не давала мне покоя, и, как объективный и беспристрастный IT-специалист, могу смело заявить: все языки программирования — говно.
Каждый из этих ваших "наборов инструкций и операторов" полон недостатков, и начнём мы, конечно, с JavaScript:
Как бы мы ни любили JS, нужно признать: этот язык — далеко не идеал. У него отсутствует четкая структура, а стандарты его столь же туманны, как утренний кофе после бессонной ночи. Прототипное ООП? Да это же настоящий музей костылей! Использование его для backend программирования — вообще анекдот. Но при всём этом, несмотря на несуразные корни и проблемы с ООП, JavaScript — это настоящий "швейцарский нож". Он проникает везде, и его универсальность — его главный козырь.
PHP
С PHP все немного иначе. Это словно друг из детства, который хоть и не самый умный, но всегда готов прийти на помощь. В нём есть всё, чтобы быстро собрать сайт "на коленке". Хотя давайте будем честными: чем глубже вы погружаетесь в проекты на PHP, тем больше встречаете кривого и непонятного кода от старых версий.
Python
Пользователи Python с их бесконечными спорами о табах и пробелах заслуживают отдельного внимания. Без фигурных скобок писать код как-то даже странно. И да, сообщество активно обсуждает, как правильно делать отступы, вместо того чтобы решать насущные проблемы производительности или многопоточности. Python хорош для скриптов и автоматизации, но как только речь заходит о более сложных проектах, вы сталкиваетесь с множеством компромиссов и костылей.
Java
Java — это как старая машина, которая по-прежнему работает, но требует слишком много ресурсов. 3 миллиарда устройств? Да, возможно. Но все знают, что Java медленно движется на старом коде и зачастую является излишне тяжёлой. Её прожорливость и неповоротливость — это испытание для любого разработчика. Каждый раз, когда вы запускаете Android Studio, вам хочется выключить обогрев в комнате — так сильно она греет наше очко.
C#
C# — это язык, который пытается быть универсальным, но порой в этом желании вы буквально тонете в типах и абстракциях. Вместо решения прикладных задач вы увязаете в типах, наследовании и бесконечных абстракциях. Это словно лабиринт, в котором, чтобы решить простую задачу, приходится блуждать, параллельно слушая советы всевозможных "гуру".
Итак, не языки определяют успех, а инструменты и фреймворки. Языки — это лишь способ подключения к действительно полезным инструментам, будь то библиотеки или платформы. Именно они делают язык популярным или нет. Завтра может появиться новый фреймворк или инструмент, который изменит правила игры, и язык, который вчера считался устаревшим, внезапно окажется в центре внимания.
Поэтому, не стоит излишне критиковать инструменты или языки. Возможно, уже через несколько лет вам самим придётся работать с тем, что сегодня кажется устаревшим или неудобным.
🔥2👍1
#News
Почему в чехарде с Discord виноват YouTube?
За последние недели развернулась нехилая Санта-Барбара по поводу блокировок. В СМИ уже как неделю вбрасываются сообщения, что Дискорд «ВОТ-ВОТ разблокируют». Его ж даже убрали с базы данных РКН, а сервис че-т все равно не запускается с российских айпишников.
Акт 1 Блокировку видишь? А она есть
Для начала вспомним эпопею с (не)блокировкой YouTube. Это было новое для нас явление. К обычным официальным блокировкам мы уже привыкли. Но в случае с Ютубом было все иначе. Официального предписания не было. Чиновники путались в мотивировке: то дело в оборудовании, то в злом Госдепе. А блокировка осуществлялась избирательным образом только на домашний интернет. Да и даже здесь итог отличался от провайдера к провайдеру.
А вот уже это запустило акт 2
Акт 2 Рыночек против деградации
Когда клиенты просекли, что блокировка ютуба по домашнему интернету работает неодинаково: у тебя нет, а у соседа да, - запускается нормальный рыночный процесс - конкуренция. Клиент начинает искать тех, кто ему предлагает лучшие условия. И ему совершенно не важно, кто там виноват: сам провайдер или цензурный орган. Поэтому он расторгает свой договор и ищет того оператора, у которого все работает. Как правило, это известные крупные игроки. А вот мелкие бизнесы начали терять деньги. Им это не понравилось. Они собрались вместе и пошли жаловаться в ФАС
Мол чего-то у одних замедляют Ютубы, а у других нет. Вы дискриминируете рынок. Это действие переносит нас в Акт 3
Акт 3 Понятные правила, понятные немногим
Когда я учился в школе, бывало такое, что учительница ставила двум работам разные оценки за одинаковые ошибки. Одному 5-, а другому 4. Хотя оба в одном месте пропустили запятую. И когда дискриминированный шел к учителю разбираться, учитель, разумеется свой просчет признать не мог. Это западло. Но не западло было уровнять результат обоим ученикам в меньшую сторону. Теперь у нас две работы с оценкой 4. И здесь я ожидал что-то подобное.
Но Роскомнадзор изобретает третий вариант. Он говорит, что просто не обязан отвечать на вопросы учеников.
11 октября, через пару недель после обращения «учеников» , РКН разрабатывает проект приказа, по которому может замедлять вообще что захочет через внесудебное решение Генпрокуратуры. А т.к. последние обладают привилегией тайны, т.е. ничего никому не объяснять и информировать, то подобная фича распространяется и на РКН. РКН назвал это «управлением сетями». В общем, не блокировка без суда и следствия, а управление сетями. Записываем в словарик.
Ну ладно, мы поняли, что коммуникация с людьми не сильная сторона великого блокиратора. Ну хотя бы на сайте РКН можем отслеживать, что нам можно смотреть, а что нет
Ну… не совсем
Акт 4 Продолжение давно идущего тренда
Когда СМИ писали, что Дискорд вот-вот разблокируют, они основывали свое предположение на исчезновении из базы РКН домена. И в целом, предположили адекватно. Но кто ж знал, что РКН втихую изменит механизм работы этой базы данных. Теперь может быть такое, что указывать надо не домен, а конкретную страницу, где размещен запрещенный материал. Страницу. В дискорде. Конкретную.
Как узнать, что именно запрещено? Ну это в списках Роскомнадзора
А как посмотреть эти списки?
¯\_(ツ)_/¯
Вот и получается, что Дискорда в базе нет, но он заблокирован. Ютуба в базе нет, но он частично замедлен.
Мы сейчас с вами входим в новую реальность, когда проверить блокировку ресурса сможем только своим лбом. Если по ходу дела спотыкаемся, а сервис открывается с помощью средств починки, значит заблочил РКН. Почему? За что? Что именно?
Знать не положено
Коммуникация 11/10
Почему в чехарде с Discord виноват YouTube?
За последние недели развернулась нехилая Санта-Барбара по поводу блокировок. В СМИ уже как неделю вбрасываются сообщения, что Дискорд «ВОТ-ВОТ разблокируют». Его ж даже убрали с базы данных РКН, а сервис че-т все равно не запускается с российских айпишников.
Акт 1 Блокировку видишь? А она есть
Для начала вспомним эпопею с (не)блокировкой YouTube. Это было новое для нас явление. К обычным официальным блокировкам мы уже привыкли. Но в случае с Ютубом было все иначе. Официального предписания не было. Чиновники путались в мотивировке: то дело в оборудовании, то в злом Госдепе. А блокировка осуществлялась избирательным образом только на домашний интернет. Да и даже здесь итог отличался от провайдера к провайдеру.
А вот уже это запустило акт 2
Акт 2 Рыночек против деградации
Когда клиенты просекли, что блокировка ютуба по домашнему интернету работает неодинаково: у тебя нет, а у соседа да, - запускается нормальный рыночный процесс - конкуренция. Клиент начинает искать тех, кто ему предлагает лучшие условия. И ему совершенно не важно, кто там виноват: сам провайдер или цензурный орган. Поэтому он расторгает свой договор и ищет того оператора, у которого все работает. Как правило, это известные крупные игроки. А вот мелкие бизнесы начали терять деньги. Им это не понравилось. Они собрались вместе и пошли жаловаться в ФАС
Мол чего-то у одних замедляют Ютубы, а у других нет. Вы дискриминируете рынок. Это действие переносит нас в Акт 3
Акт 3 Понятные правила, понятные немногим
Когда я учился в школе, бывало такое, что учительница ставила двум работам разные оценки за одинаковые ошибки. Одному 5-, а другому 4. Хотя оба в одном месте пропустили запятую. И когда дискриминированный шел к учителю разбираться, учитель, разумеется свой просчет признать не мог. Это западло. Но не западло было уровнять результат обоим ученикам в меньшую сторону. Теперь у нас две работы с оценкой 4. И здесь я ожидал что-то подобное.
Но Роскомнадзор изобретает третий вариант. Он говорит, что просто не обязан отвечать на вопросы учеников.
11 октября, через пару недель после обращения «учеников» , РКН разрабатывает проект приказа, по которому может замедлять вообще что захочет через внесудебное решение Генпрокуратуры. А т.к. последние обладают привилегией тайны, т.е. ничего никому не объяснять и информировать, то подобная фича распространяется и на РКН. РКН назвал это «управлением сетями». В общем, не блокировка без суда и следствия, а управление сетями. Записываем в словарик.
Ну ладно, мы поняли, что коммуникация с людьми не сильная сторона великого блокиратора. Ну хотя бы на сайте РКН можем отслеживать, что нам можно смотреть, а что нет
Ну… не совсем
Акт 4 Продолжение давно идущего тренда
Когда СМИ писали, что Дискорд вот-вот разблокируют, они основывали свое предположение на исчезновении из базы РКН домена. И в целом, предположили адекватно. Но кто ж знал, что РКН втихую изменит механизм работы этой базы данных. Теперь может быть такое, что указывать надо не домен, а конкретную страницу, где размещен запрещенный материал. Страницу. В дискорде. Конкретную.
Как узнать, что именно запрещено? Ну это в списках Роскомнадзора
А как посмотреть эти списки?
¯\_(ツ)_/¯
Вот и получается, что Дискорда в базе нет, но он заблокирован. Ютуба в базе нет, но он частично замедлен.
Мы сейчас с вами входим в новую реальность, когда проверить блокировку ресурса сможем только своим лбом. Если по ходу дела спотыкаемся, а сервис открывается с помощью средств починки, значит заблочил РКН. Почему? За что? Что именно?
Знать не положено
Коммуникация 11/10
#Education #Python
Если решил учить Python, браток, добро пожаловать в хату питонистов. Тут, знаешь ли, свои правила — на базу не по фене ботать не получится, придётся научиться шарить не только за циклы и функции, но и за то, как правильно двигать по жизни.
Первое, что тебе надо понять: заходишь в проект — заходи с умом. Если ты тут по красивую жизнь пришёл и думаешь, что Python'чик тебя на райские пет-проектики выведет — хаха, держи карман шире! Ты теперь на зоне, и тут такие штуки, как баги, костыли и дедлайны — как масти в картах, всегда с тобой.
Сокамерники могут быть разные — от джунов до сеньоров, но знай: дедуля твой SRP — это как устав. Ты чётко должен всем сказать: «Мужики, у меня одна обязанность, или я тут дебагом занимаюсь, или код пилю. В две работы вписываться не буду, с пониманием отнеситесь». А за «Open-Closed» лучше молчи, это вам не на воле — никто расширяться не хочет, максимум, что тебя ждёт — это лишний таск на шею.
В Python всё просто: задачку вкатили — решай. Только ты знаешь, что всегда будет два стула. На одном — «геморойная оптимизация кода», на другом — «залезть в чужие костыли и понять, кто тут батя». Вот и думай, на какой сесть.
Короче, Python — штука гибкая, но учись правильно раскидывать по камере свои задачи. Не тупи, асинхронку тут все уважают, потому что никто не хочет чтобы система висла, как лох-javaScript'езер. Тебе ж не охота стать «тем, кто завалил проект», да?
Так что грей стэк, уважай принципы, и твой питоновский путь будет ровным, без лишнего напряга.
Если решил учить Python, браток, добро пожаловать в хату питонистов. Тут, знаешь ли, свои правила — на базу не по фене ботать не получится, придётся научиться шарить не только за циклы и функции, но и за то, как правильно двигать по жизни.
Первое, что тебе надо понять: заходишь в проект — заходи с умом. Если ты тут по красивую жизнь пришёл и думаешь, что Python'чик тебя на райские пет-проектики выведет — хаха, держи карман шире! Ты теперь на зоне, и тут такие штуки, как баги, костыли и дедлайны — как масти в картах, всегда с тобой.
Сокамерники могут быть разные — от джунов до сеньоров, но знай: дедуля твой SRP — это как устав. Ты чётко должен всем сказать: «Мужики, у меня одна обязанность, или я тут дебагом занимаюсь, или код пилю. В две работы вписываться не буду, с пониманием отнеситесь». А за «Open-Closed» лучше молчи, это вам не на воле — никто расширяться не хочет, максимум, что тебя ждёт — это лишний таск на шею.
В Python всё просто: задачку вкатили — решай. Только ты знаешь, что всегда будет два стула. На одном — «геморойная оптимизация кода», на другом — «залезть в чужие костыли и понять, кто тут батя». Вот и думай, на какой сесть.
Короче, Python — штука гибкая, но учись правильно раскидывать по камере свои задачи. Не тупи, асинхронку тут все уважают, потому что никто не хочет чтобы система висла, как лох-javaScript'езер. Тебе ж не охота стать «тем, кто завалил проект», да?
Так что грей стэк, уважай принципы, и твой питоновский путь будет ровным, без лишнего напряга.
#OOP #Paradigms
Один маслёнок яростно доказывал что ООП очень хорошо заходит для создания GUI. Ответ специально для него:
Ооо дружище, ООП харош для GUI? Это примерно такой же спид как и про то что ООП харош для всего когда программисты обожглись об ООП, но проблему GUI глубже фармашлёпства не исследовали, поэтому решили: "Ну ладно, ООП для моей предметной области говно"; но ведь кнопка это же объект, ты ведь понимаешь о чем я, уёбок?
Повторю другими словами: когда ты был маленьким и глупым, и нихуя не шарил в своей предметной области, ты думал что всё есть некий абстрактный объект и что ООП идеально его моделирует. Потом ты немного подрос и поумнел, и выделил в своей области множество взаимосвязей и закономерностей и она наполнилась морфизмами, фунторами, отражениями, естественным преобразованием, пределами, ку-пределами, сопряжениями и прочими знаниями, для моделирования которых убогое ООП ну никак не подходит.
А GUI так и остался той областью в которой ты нихуя не шаришь. Так вот, уёбок, не надо экстраполировать свою самоуверенность на все отрасли человеческой деятельности. Если ты охуенный спец по обработке сигналов, это еще не значит что ты охуенный спец по чистке туалетов или лепке CRUD'ов. И если ты в лепке CRUD'ов не видишь никаких закономерностей это не значит что их там нет и что любой виджет есть объект и не более того, закономерностей там больше чем дохуя.
Я вот с ходу могу сказать что GUI лучше моделировать стрелками чем объектами, а истинный спец по GUI тебе наверняка категорий 5 навернет охватывающих визуализаций, валидаций, интернациализаций и локализаций, layout'ы для людей с ограниченными возможностями и хуй че там еще может быть. Поэтому говори про то что знаешь, про GUI пусть спецы по GUI пишут, от них то мы и узнаем, столь ли там харош ООП или приходиться еще каким-нибудь xml в жепу поябываться.
Один маслёнок яростно доказывал что ООП очень хорошо заходит для создания GUI. Ответ специально для него:
Ооо дружище, ООП харош для GUI? Это примерно такой же спид как и про то что ООП харош для всего когда программисты обожглись об ООП, но проблему GUI глубже фармашлёпства не исследовали, поэтому решили: "Ну ладно, ООП для моей предметной области говно"; но ведь кнопка это же объект, ты ведь понимаешь о чем я, уёбок?
Повторю другими словами: когда ты был маленьким и глупым, и нихуя не шарил в своей предметной области, ты думал что всё есть некий абстрактный объект и что ООП идеально его моделирует. Потом ты немного подрос и поумнел, и выделил в своей области множество взаимосвязей и закономерностей и она наполнилась морфизмами, фунторами, отражениями, естественным преобразованием, пределами, ку-пределами, сопряжениями и прочими знаниями, для моделирования которых убогое ООП ну никак не подходит.
А GUI так и остался той областью в которой ты нихуя не шаришь. Так вот, уёбок, не надо экстраполировать свою самоуверенность на все отрасли человеческой деятельности. Если ты охуенный спец по обработке сигналов, это еще не значит что ты охуенный спец по чистке туалетов или лепке CRUD'ов. И если ты в лепке CRUD'ов не видишь никаких закономерностей это не значит что их там нет и что любой виджет есть объект и не более того, закономерностей там больше чем дохуя.
Я вот с ходу могу сказать что GUI лучше моделировать стрелками чем объектами, а истинный спец по GUI тебе наверняка категорий 5 навернет охватывающих визуализаций, валидаций, интернациализаций и локализаций, layout'ы для людей с ограниченными возможностями и хуй че там еще может быть. Поэтому говори про то что знаешь, про GUI пусть спецы по GUI пишут, от них то мы и узнаем, столь ли там харош ООП или приходиться еще каким-нибудь xml в жепу поябываться.
🤡1
#ITLife
Деды в программировании:
Давайте поговорим о наших любимых "дедах" в программировании. Знаете, тех самых, кто считает что знание всех теоретических основ — это единственный путь к успеху.
Вот например ситуация: преподаватель спрашивает, что такое атрибуты в контексте БД. Один из студентов отвечает что это набор строк, и тут же получает угрозу: "Ты еще раз так ответишь — выгоню тебя!" А потом, когда речь заходит о домене, все молчат и начинается: "Вы не программисты, никому не нужны! итд итп"
Серьезно? Программист — это не тот кто может заучить все определения и термины, а тот, кто на практике создал что-то действительно стоящее, вроде нового Google или Windows. Да, база знаний важна, но ставить теорию в приоритет — это все равно что думать о быстродействии кода, когда ты еще не научился его писать.
И вот из-за таких "дедов" у нас есть целая армия людей, которые могут стараться, но из-за того что они не знают 858657 вариантов пузырьковой сортировки, их просто выгоняют с собеседований.
Так что давайте помнить: программирование — это не только про теорию, но и про практику. И если вы не знаете как сделать что-то на практике, то все ваши знания о терминах и определениях — это просто набор строк.
В общем, давайте учиться, экспериментировать и не забывать что в программировании главное — это результат, а не количество заученных терминов!!!
Деды в программировании:
Давайте поговорим о наших любимых "дедах" в программировании. Знаете, тех самых, кто считает что знание всех теоретических основ — это единственный путь к успеху.
Вот например ситуация: преподаватель спрашивает, что такое атрибуты в контексте БД. Один из студентов отвечает что это набор строк, и тут же получает угрозу: "Ты еще раз так ответишь — выгоню тебя!" А потом, когда речь заходит о домене, все молчат и начинается: "Вы не программисты, никому не нужны! итд итп"
Серьезно? Программист — это не тот кто может заучить все определения и термины, а тот, кто на практике создал что-то действительно стоящее, вроде нового Google или Windows. Да, база знаний важна, но ставить теорию в приоритет — это все равно что думать о быстродействии кода, когда ты еще не научился его писать.
И вот из-за таких "дедов" у нас есть целая армия людей, которые могут стараться, но из-за того что они не знают 858657 вариантов пузырьковой сортировки, их просто выгоняют с собеседований.
Так что давайте помнить: программирование — это не только про теорию, но и про практику. И если вы не знаете как сделать что-то на практике, то все ваши знания о терминах и определениях — это просто набор строк.
В общем, давайте учиться, экспериментировать и не забывать что в программировании главное — это результат, а не количество заученных терминов!!!
#meme
Давайте разберёмся, что на самом деле нужно для старта в IT. Вот идеальный (нет) набор изысканных книг и статей, который на первый взгляд кажутся полезными, но на деле могут увести в глубокие дебри:
3 томика Кнута — о да, забудьте про это, если хотите не просто учиться, а выживать! Чтение Кнута в первые месяцы гарантирует, что вы навсегда запомните, что такое показатель сложности алгоритма… в других измерениях. 🌌
75 статей по устройству памяти — зачем тратить время на такие вещи? Лучше поищите статью о том как запомнить где вы оставили свой кофе! ☕️
5 уровней по системной инженерии и OSI — на этом этапе я бы уже посоветовал записаться на курсы по медитации. После нескольких часов «уровней» вы точно поймёте, как правильно успокаиваться когда начинаете забивать на все эти сложные схемы. 🧘♂️
SSD, наполовину заполненный реализациями алгоритмов и структур — да кто вообще пользуется SSD в 2024 году? Все знают, что лучше хранить всё в облаке, потому что «вдруг сгорит»! (шутка) ☁️🔥
Целое море разноцветных книг по чистоте кода:
Макконнелл, Мартин и Свейгард — если вы не знаете, что они написали, это просто шикарно. Зачем заботиться о чистоте, если код и так работает? Не забывайте: чистый код — это тот, который не трогали!
Томик Николауса Вирта — конечно, если вам интересна история программирования и вы хотите узнать, как кодили в каменном веке. 🦕
Шпаргалка по Linux'y — как же без этого? Но скажите, кто вообще помнит как устанавливать программы без графического интерфейса? Серьёзно, для чего нам это? 😂
Книга Таненбаума — прекрасное чтиво для тех, кто хочет понять как работает операционная система, но не хочет просыпаться каждое утро с головной болью.
И 12 сайтов самоучителей — ну а если по-правде, тогда можно было бы оставить только 1: Как не сломать свой компьютер за 5 шагов. Вполне достаточно! 💻💔
Вот так, с одной стороны, надёжная база для старта, а с другой — настоящие legacy! Не дайте себе заблудиться в этом книжном аду. Достаточно пары видеороликов на YouTube и хорошего практического опыта чтобы стать профи. Так что, если вы только начинаете, просто помните:
Давайте разберёмся, что на самом деле нужно для старта в IT. Вот идеальный (нет) набор изысканных книг и статей, который на первый взгляд кажутся полезными, но на деле могут увести в глубокие дебри:
3 томика Кнута — о да, забудьте про это, если хотите не просто учиться, а выживать! Чтение Кнута в первые месяцы гарантирует, что вы навсегда запомните, что такое показатель сложности алгоритма… в других измерениях. 🌌
75 статей по устройству памяти — зачем тратить время на такие вещи? Лучше поищите статью о том как запомнить где вы оставили свой кофе! ☕️
5 уровней по системной инженерии и OSI — на этом этапе я бы уже посоветовал записаться на курсы по медитации. После нескольких часов «уровней» вы точно поймёте, как правильно успокаиваться когда начинаете забивать на все эти сложные схемы. 🧘♂️
SSD, наполовину заполненный реализациями алгоритмов и структур — да кто вообще пользуется SSD в 2024 году? Все знают, что лучше хранить всё в облаке, потому что «вдруг сгорит»! (шутка) ☁️🔥
Целое море разноцветных книг по чистоте кода:
Макконнелл, Мартин и Свейгард — если вы не знаете, что они написали, это просто шикарно. Зачем заботиться о чистоте, если код и так работает? Не забывайте: чистый код — это тот, который не трогали!
Томик Николауса Вирта — конечно, если вам интересна история программирования и вы хотите узнать, как кодили в каменном веке. 🦕
Шпаргалка по Linux'y — как же без этого? Но скажите, кто вообще помнит как устанавливать программы без графического интерфейса? Серьёзно, для чего нам это? 😂
Книга Таненбаума — прекрасное чтиво для тех, кто хочет понять как работает операционная система, но не хочет просыпаться каждое утро с головной болью.
И 12 сайтов самоучителей — ну а если по-правде, тогда можно было бы оставить только 1: Как не сломать свой компьютер за 5 шагов. Вполне достаточно! 💻💔
Вот так, с одной стороны, надёжная база для старта, а с другой — настоящие legacy! Не дайте себе заблудиться в этом книжном аду. Достаточно пары видеороликов на YouTube и хорошего практического опыта чтобы стать профи. Так что, если вы только начинаете, просто помните:
Не учите то, что вам не нужно — это будет уже не IT, а просто название вашей библиотеки! 📚💥
#Other
Представим, что языки программирования — это люди, а значит по моему единственному и правильному мнению они выглядят так:
Python: Популярный парень, который всегда готов прийти на помощь и сделать все быстро. Он умеет решать проблемы и любит экспериментировать. Однако, несмотря на его полезность, глупо шутит и порой ведет себя то как душа компании, то как клоун
C++: Высокий, умный молодой человек. Баскетболит. Выше всех на тусовке. Неплохо соображает, может удивить своей памятью. Никто не скажет, что провести с ним время будет безопасно, но все будет хорошо, если пользоваться защитой. Несмотря на его способности, его считают парнем со своими загонами, сложностями. И вкатуны обычно выбирают либо С#, либо С. Оставляя С++ для тех, кто любит разные "игры"
C: Классный парень, который любит мастерить вещи своими руками. Он уважаем в сообществе за свою надежность. Он является лучшим выбором для тех, кто разделяет его хобби и любит что-то делать руками
Java: Вечно устаревший мужчина, который продолжает использовать старые методы, несмотря на новые возможности. Его сложно воспринимать серьезно, но в сообществе его уважают за стабильность
Kotlin: Младшая сестра Java, которая пытается выделиться и стать лучше своего старшего брата. Она красива и дружелюбна, но ограничена в своих возможностях воспитанием
C#: Обаятельный и умный молодой человек, который может справиться практически с любой задачей. Хотя его отец вызывает сомнения, он остается любимчиком многих благодаря своим способностям
F#: Младший брат C#, но гораздо более замкнутый и увлеченный всякими странными теоретическими штуками. Постоянно ходит с блокнотом и пытается уговорить людей изучить функциональное программирование. Но всем почему-то кажется, что у него слишком сложные идеи для простого общения.
HTML: Прекрасная девушка, всегда стильно одетая и со вкусом. Она — основа всего, на что ты смотришь, но почему-то многие недооценивают её значимость. Её часто принимают за "простой" язык, но без неё вечеринка была бы совсем не такой яркой. Она не спорит с другими, просто молча продолжает делать своё дело.
CSS: Это лучшая подруга HTML. Она всегда в центре внимания благодаря своему чувству стиля и способностям делать всё красивым. Её работа может быть сложной, потому что она постоянно экспериментирует с новыми тенденциями. Иногда она может стать капризной, но все понимают, что без неё вечеринка была бы скучной и серой.
JavaScript: Красивый и загадочный персонаж, который привлекает внимание всех на вечеринке. Он обещает многое, но требует много усилий и внимания. С ним нелегко расставаться, и его еженедельные выходки могут стать головной болью
TypeScript: JavaScript в очках с прилизанными волосами, который решил поумнеть. Он выглядит более уверенным и уравновешенным, постоянно исправляет своего старшего брата на тусовке. Но иногда за это его раздражает вся компания, особенно когда выясняется, что он просто подражает другим умникам.
SQL и CQL: Два брата, которые известны каждому и находятся в центре внимания. Они общаются со всеми и всегда помогут
Go: Простодушный парень, который быстро учится, но не очень хорошо справляется с серьезными задачами. Он предпочитает быстрые решения и легко адаптируется к новым условиям. Он богат, но не очень популярен среди зарубежных вкатунов
PHP: Парень, который всегда рядом, когда нужна быстрая помощь. Он может выглядеть менее стильно, как Python, но у него всегда найдется место, чтобы провести вечеринку
Swift: Она молода, красива и обожает роскошные вещи. Она не разговаривает с теми, у кого нет "яблочной" техники, но когда у тебя всё по её стандартам, она работает быстро и элегантно. Одевается со вкусом, но может немного напрягать своим высокомерным отношением к тем, кто использует "неправильные" устройства.
VBA: Бухгалтер на вечеринке, который, кажется, знает пару классных трюков с таблицами Excel. Всех удивляет, как он всё это делает, но никто не хочет стоять рядом с ним, боясь, что он начнёт объяснять, как автоматизировать отчетность.
Представим, что языки программирования — это люди, а значит по моему единственному и правильному мнению они выглядят так:
Python: Популярный парень, который всегда готов прийти на помощь и сделать все быстро. Он умеет решать проблемы и любит экспериментировать. Однако, несмотря на его полезность, глупо шутит и порой ведет себя то как душа компании, то как клоун
C++: Высокий, умный молодой человек. Баскетболит. Выше всех на тусовке. Неплохо соображает, может удивить своей памятью. Никто не скажет, что провести с ним время будет безопасно, но все будет хорошо, если пользоваться защитой. Несмотря на его способности, его считают парнем со своими загонами, сложностями. И вкатуны обычно выбирают либо С#, либо С. Оставляя С++ для тех, кто любит разные "игры"
C: Классный парень, который любит мастерить вещи своими руками. Он уважаем в сообществе за свою надежность. Он является лучшим выбором для тех, кто разделяет его хобби и любит что-то делать руками
Java: Вечно устаревший мужчина, который продолжает использовать старые методы, несмотря на новые возможности. Его сложно воспринимать серьезно, но в сообществе его уважают за стабильность
Kotlin: Младшая сестра Java, которая пытается выделиться и стать лучше своего старшего брата. Она красива и дружелюбна, но ограничена в своих возможностях воспитанием
C#: Обаятельный и умный молодой человек, который может справиться практически с любой задачей. Хотя его отец вызывает сомнения, он остается любимчиком многих благодаря своим способностям
F#: Младший брат C#, но гораздо более замкнутый и увлеченный всякими странными теоретическими штуками. Постоянно ходит с блокнотом и пытается уговорить людей изучить функциональное программирование. Но всем почему-то кажется, что у него слишком сложные идеи для простого общения.
HTML: Прекрасная девушка, всегда стильно одетая и со вкусом. Она — основа всего, на что ты смотришь, но почему-то многие недооценивают её значимость. Её часто принимают за "простой" язык, но без неё вечеринка была бы совсем не такой яркой. Она не спорит с другими, просто молча продолжает делать своё дело.
CSS: Это лучшая подруга HTML. Она всегда в центре внимания благодаря своему чувству стиля и способностям делать всё красивым. Её работа может быть сложной, потому что она постоянно экспериментирует с новыми тенденциями. Иногда она может стать капризной, но все понимают, что без неё вечеринка была бы скучной и серой.
JavaScript: Красивый и загадочный персонаж, который привлекает внимание всех на вечеринке. Он обещает многое, но требует много усилий и внимания. С ним нелегко расставаться, и его еженедельные выходки могут стать головной болью
TypeScript: JavaScript в очках с прилизанными волосами, который решил поумнеть. Он выглядит более уверенным и уравновешенным, постоянно исправляет своего старшего брата на тусовке. Но иногда за это его раздражает вся компания, особенно когда выясняется, что он просто подражает другим умникам.
SQL и CQL: Два брата, которые известны каждому и находятся в центре внимания. Они общаются со всеми и всегда помогут
Go: Простодушный парень, который быстро учится, но не очень хорошо справляется с серьезными задачами. Он предпочитает быстрые решения и легко адаптируется к новым условиям. Он богат, но не очень популярен среди зарубежных вкатунов
PHP: Парень, который всегда рядом, когда нужна быстрая помощь. Он может выглядеть менее стильно, как Python, но у него всегда найдется место, чтобы провести вечеринку
Swift: Она молода, красива и обожает роскошные вещи. Она не разговаривает с теми, у кого нет "яблочной" техники, но когда у тебя всё по её стандартам, она работает быстро и элегантно. Одевается со вкусом, но может немного напрягать своим высокомерным отношением к тем, кто использует "неправильные" устройства.
VBA: Бухгалтер на вечеринке, который, кажется, знает пару классных трюков с таблицами Excel. Всех удивляет, как он всё это делает, но никто не хочет стоять рядом с ним, боясь, что он начнёт объяснять, как автоматизировать отчетность.
❤2🔥1
#meme
🌟 Java Программист 🌟
Представьте себе: в углу комнаты сидит Java программист, выглядя так, будто только что вышел из библиотеки. В очках и с необычной прической он неустанно делится своими мыслями о программировании.
"Это объектно-ориентированно!" — говорит он и вы понимаете, что это не просто слова, а его образ жизни. Он с гордостью утверждает, что "JVM — это лучшая виртуальная машина в мире", а "Garbage Collection — идеальный способ управления памятью".
Для него Java не просто язык, это язык будущего! "Все должны использовать Java!" — настаивает он, уверенный в своей правоте. В его мире нет места для других языков программирования.
Когда разговор заходит о реальных проектах он начинает рассказывать о своих университетских достижениях, подчеркивая, как это было сложно. "Это должно быть сделано по-энтерпрайзному!" — повторяет он, используя слова "архитектура", "паттерны" и "дизайн" в каждом предложении, даже когда это неуместно.
И вот когда ночь становится поздней, а остальные начинают расходиться, наш Java программист остается в углу, погруженный в мысли о том как улучшить свой код и решить проблемы с памятью в Java.
💻✨ Java — это не просто язык, это стиль жизни! ✨💻
🌟 Java Программист 🌟
Представьте себе: в углу комнаты сидит Java программист, выглядя так, будто только что вышел из библиотеки. В очках и с необычной прической он неустанно делится своими мыслями о программировании.
"Это объектно-ориентированно!" — говорит он и вы понимаете, что это не просто слова, а его образ жизни. Он с гордостью утверждает, что "JVM — это лучшая виртуальная машина в мире", а "Garbage Collection — идеальный способ управления памятью".
Для него Java не просто язык, это язык будущего! "Все должны использовать Java!" — настаивает он, уверенный в своей правоте. В его мире нет места для других языков программирования.
Когда разговор заходит о реальных проектах он начинает рассказывать о своих университетских достижениях, подчеркивая, как это было сложно. "Это должно быть сделано по-энтерпрайзному!" — повторяет он, используя слова "архитектура", "паттерны" и "дизайн" в каждом предложении, даже когда это неуместно.
И вот когда ночь становится поздней, а остальные начинают расходиться, наш Java программист остается в углу, погруженный в мысли о том как улучшить свой код и решить проблемы с памятью в Java.
💻✨ Java — это не просто язык, это стиль жизни! ✨💻
#Linux #OS
Дистрибутивы Linux — это как разные сорта пива: у каждого свои фанаты, и каждый считает, что именно его выбор — вершина эволюции. Давайте разберём несколько популярных дистрибутивов.
Ubuntu: Это как тот парень, который всегда приходит на вечеринку с пиццей и пивом. Все его любят, но никто не понимает, почему он так часто обновляется. "Я просто хочу, чтобы у меня было всё самое новое!" — говорит он, пока его система зависает на 30% загрузки. Ubuntu — идеальный выбор для тех, кто хочет попробовать Linux, но не желает углубляться в философию и терминологию. "Просто нажми на кнопку, и всё будет работать!" — как будто это не обман.
Arch Linux: Это дистрибутив для тех, кто любит страдать. "Собери свою систему сам!" — кричат фанаты Arch, как будто это не просто способ заставить вас потратить выходные на установку драйверов. Arch — это как квест в видеоигре, где вместо драконов и сокровищ вы сражаетесь с зависимостями и конфигурационными файлами. "Собери свою систему сам!" — и ты понимаешь, что собрал только сломанный компьютер и кучу нервов.
Debian: Это как ваш дедушка, который всегда говорит: "В моё время всё было лучше!" Debian — это стабильность, но такая стабильность, что иногда кажется, что он просто забыл, что такое обновления. "Зачем обновляться, если всё и так работает?" — философия, которая может привести к тому, что вы будете использовать софт, актуальный ещё во времена динозавров.
Fedora: Это дистрибутив для тех, кто хочет быть на передовой технологий, но не хочет, чтобы это было слишком сложно. "Я использую Fedora, потому что люблю быть в тренде!" — говорит он, пока его система не решает, что обновление ядра — это отличная идея в самый неподходящий момент. Fedora — это как модный магазин, где все вещи выглядят круто, но на самом деле их никто не носит.
Mint: Это дистрибутив для тех, кто хочет, чтобы всё выглядело красиво и работало без проблем. "Я просто хочу, чтобы всё было как в Windows, но без вирусов!" — говорит он, пока его система не решает, что обновления — это не для него. Mint — это как уютный диван, на котором приятно сидеть, но который может неожиданно провалиться под вами.
Дистрибутивы Linux — это как разные сорта пива: у каждого свои фанаты, и каждый считает, что именно его выбор — вершина эволюции. Давайте разберём несколько популярных дистрибутивов.
Ubuntu: Это как тот парень, который всегда приходит на вечеринку с пиццей и пивом. Все его любят, но никто не понимает, почему он так часто обновляется. "Я просто хочу, чтобы у меня было всё самое новое!" — говорит он, пока его система зависает на 30% загрузки. Ubuntu — идеальный выбор для тех, кто хочет попробовать Linux, но не желает углубляться в философию и терминологию. "Просто нажми на кнопку, и всё будет работать!" — как будто это не обман.
Arch Linux: Это дистрибутив для тех, кто любит страдать. "Собери свою систему сам!" — кричат фанаты Arch, как будто это не просто способ заставить вас потратить выходные на установку драйверов. Arch — это как квест в видеоигре, где вместо драконов и сокровищ вы сражаетесь с зависимостями и конфигурационными файлами. "Собери свою систему сам!" — и ты понимаешь, что собрал только сломанный компьютер и кучу нервов.
Debian: Это как ваш дедушка, который всегда говорит: "В моё время всё было лучше!" Debian — это стабильность, но такая стабильность, что иногда кажется, что он просто забыл, что такое обновления. "Зачем обновляться, если всё и так работает?" — философия, которая может привести к тому, что вы будете использовать софт, актуальный ещё во времена динозавров.
Fedora: Это дистрибутив для тех, кто хочет быть на передовой технологий, но не хочет, чтобы это было слишком сложно. "Я использую Fedora, потому что люблю быть в тренде!" — говорит он, пока его система не решает, что обновление ядра — это отличная идея в самый неподходящий момент. Fedora — это как модный магазин, где все вещи выглядят круто, но на самом деле их никто не носит.
Mint: Это дистрибутив для тех, кто хочет, чтобы всё выглядело красиво и работало без проблем. "Я просто хочу, чтобы всё было как в Windows, но без вирусов!" — говорит он, пока его система не решает, что обновления — это не для него. Mint — это как уютный диван, на котором приятно сидеть, но который может неожиданно провалиться под вами.
В общем, дистрибутивы Linux — это как большая семья, где каждый член считает себя самым умным и самым красивым. И, как в любой семье, иногда хочется просто закрыть дверь и не слышать их споры о том, какой дистрибутив лучше. Но, в конце концов, главное — это то, что каждый находит свой путь в этом безумном мире технологий.
#Education #OpenSource
GIT для маслят: как не закоммитить стыд в репозиторий
Итак, маслята, вы решили вкатиться в программирование, и вам говорят: «Бро, запушь на гитхаб». А вы такие: «Гит-чо?» Не беда! Сейчас разберёмся, как пользоваться этой магией.
Заводим свой первый проект на гит:
Это как если бы вы сказали: «Всё, теперь тут сохранёнка». С этого момента ваш код будет под гитовой защитой.
Вы написали пару строчек кода, и теперь хотите, чтобы гит посмотрел на это? Легко!
С этой командой вы говорите: «Гит, глянь на всё, что я тут наваял». Точка в конце означает «добавь всё». Да, можно выбрать отдельные файлы, но маслята не ищут лёгких путей!
После того, как вы добавили всё, что захотели, нужно официально засвидетельствовать свой позор (или успех).
Эта команда — как галочка на ЕГЭ: вот теперь это навсегда. Коммитим. Обязательно оставляйте осмысленные комментарии, чтобы через месяц не сидеть с лицом Чарли Дэя, разбираясь, что вы там натворили.
Теперь надо убедиться, что вы на правильной ветке. Называем её «main», потому что так теперь модно.
Ветка — это как ваша параллельная вселенная. Делайте их столько, сколько хотите, но помните: сливать вселенные опасно!
Создаёте репозиторий на GitHub (да-да, там жмёте всякие кнопочки), а потом связываете его с вашим локальным репозиторием:
Это как дать вашему проекту билет на самолёт и сказать: «Лети, мой код, и покажи миру, на что ты способен!».
Время распахнуть дверь в мир!
Это команда для героев: ваш код улетает в репозиторий и начинает своё существование на GitHub. Не забудьте проверить, что вы действительно хотите показать людям. Иначе начнутся те самые коммиты типа fix bugs, last fix, really last fix и WTF?!?!.
Но что делать, если код уже запушен и всё норм, а тут внезапно вылезли какие-то баги? Или коллега наваял шедевр за вас? Просто стяните последние изменения:
Это как Ctrl+Z для реальной жизни. Приняли изменения, посмотрели, порадовались, а потом аккуратно нафигачили что-то своё.
Хотите скачать проект, как мемас из интернета? Легко!
Теперь вы у себя на компе «клонировали» весь репозиторий с гитхаба. Можете начать колдовать.
Не помните, что происходит в репозитории? Какой у вас статус? Коммиты сделаны или где-то косяк? Просто спросите:
Эта команда — как магическое зеркало, покажет вам все незакоммиченные файлы и их статус.
Хотите узнать всю историю своего позора?
Посмотрите на свои старые коммиты и всплакните от того, каким вы были молодым и глупым.
Захотели добавить что-то новое, но не хотите разрушить всё, что было? Создайте новую ветку и колдуйте там:
Это как мини-вселенная для ваших экспериментов, где можно быть безумным гением и не бояться, что код упадёт.
Заключение
GIT для маслят: как не закоммитить стыд в репозиторий
Итак, маслята, вы решили вкатиться в программирование, и вам говорят: «Бро, запушь на гитхаб». А вы такие: «Гит-чо?» Не беда! Сейчас разберёмся, как пользоваться этой магией.
1. git init
Заводим свой первый проект на гит:
$ git init
Это как если бы вы сказали: «Всё, теперь тут сохранёнка». С этого момента ваш код будет под гитовой защитой.
2. git add .
Вы написали пару строчек кода, и теперь хотите, чтобы гит посмотрел на это? Легко!
$ git add .
С этой командой вы говорите: «Гит, глянь на всё, что я тут наваял». Точка в конце означает «добавь всё». Да, можно выбрать отдельные файлы, но маслята не ищут лёгких путей!
3. git commit -m "My first commit"
После того, как вы добавили всё, что захотели, нужно официально засвидетельствовать свой позор (или успех).
$ git commit -m "My first commit"
Эта команда — как галочка на ЕГЭ: вот теперь это навсегда. Коммитим. Обязательно оставляйте осмысленные комментарии, чтобы через месяц не сидеть с лицом Чарли Дэя, разбираясь, что вы там натворили.
4. git branch -M main
Теперь надо убедиться, что вы на правильной ветке. Называем её «main», потому что так теперь модно.
$ git branch -M main
Ветка — это как ваша параллельная вселенная. Делайте их столько, сколько хотите, но помните: сливать вселенные опасно!
5. git remote add origin
Создаёте репозиторий на GitHub (да-да, там жмёте всякие кнопочки), а потом связываете его с вашим локальным репозиторием:
$ git remote add origin https://github.com/maslenok/myrepo.git
Это как дать вашему проекту билет на самолёт и сказать: «Лети, мой код, и покажи миру, на что ты способен!».
6. git push -u origin main
Время распахнуть дверь в мир!
$ git push -u origin main
Это команда для героев: ваш код улетает в репозиторий и начинает своё существование на GitHub. Не забудьте проверить, что вы действительно хотите показать людям. Иначе начнутся те самые коммиты типа fix bugs, last fix, really last fix и WTF?!?!.
7. git pull
Но что делать, если код уже запушен и всё норм, а тут внезапно вылезли какие-то баги? Или коллега наваял шедевр за вас? Просто стяните последние изменения:
$ git pull
Это как Ctrl+Z для реальной жизни. Приняли изменения, посмотрели, порадовались, а потом аккуратно нафигачили что-то своё.
8. git clone
Хотите скачать проект, как мемас из интернета? Легко!
$ git clone https://github.com/maslenok/chelovek-kot.git
Теперь вы у себя на компе «клонировали» весь репозиторий с гитхаба. Можете начать колдовать.
9. git status
Не помните, что происходит в репозитории? Какой у вас статус? Коммиты сделаны или где-то косяк? Просто спросите:
$ git status
Эта команда — как магическое зеркало, покажет вам все незакоммиченные файлы и их статус.
10. git log
Хотите узнать всю историю своего позора?
$ git log
Посмотрите на свои старые коммиты и всплакните от того, каким вы были молодым и глупым.
11. git checkout -b "feature"
Захотели добавить что-то новое, но не хотите разрушить всё, что было? Создайте новую ветку и колдуйте там:
$ git checkout -b "feature"
Это как мини-вселенная для ваших экспериментов, где можно быть безумным гением и не бояться, что код упадёт.
Заключение
Гит — это как ваше магическое хранилище, где можно сохранять все свои успехи, провалы и шедевры. Главное — не забывайте делать коммиты с нормальными сообщениями, а то потом будете вспоминать, что такое final-final-absolutely-final-v2.
Так что, маслята, теперь вы знаете базу. Идите, творите и пушьте. И не забывайте: Ctrl+C, Ctrl+V — это тоже программирование.
Niwe Code
#Education #OpenSource GIT для маслят: как не закоммитить стыд в репозиторий Итак, маслята, вы решили вкатиться в программирование, и вам говорят: «Бро, запушь на гитхаб». А вы такие: «Гит-чо?» Не беда! Сейчас разберёмся, как пользоваться этой магией. 1.…
Поделиться проектом на GitHub Final.txt
4.3 KB
#News #Linux
Скандал в мире Open Source: исключение российских разработчиков из ядра Linux
Недавние события вокруг разработчиков ядра Linux вызвали многочисленные споры и недоумение. Один из главных разработчиков ядра принял решение исключить 11 российских разработчиков, которые в некоторых случаях более 10 лет вносят свой вклад в проект.
Причина? «Потому что российские разработчики и Россия». 🎤💥
Многие из уволенных уже долгое время живут за пределами России, но это не помогло им остаться в проекте. Линус Торвальдс, основатель Linux, пояснил ситуацию, но отклонился от обсуждения деталей, ссылаясь на указания юристов.
Некоторые участники сообщества начали задаваться вопросами: что же произошло на самом деле? Какова истинная причина исключений? В конце концов, такая ситуация ставит под сомнение принципы, на которых строится open source более 25 лет.
Важно отметить, что Linux Foundation заявлял о нейтралитете open source в политике, но выводы, сделанные в этом случае, ставят это под сомнение. 🤔
На фоне этой ситуации, участники сообщества чувствуют напряжение и недоумение. Так ли просто развенчать все принципы открытости и сотрудничества, на которых была основана вся экосистема?
Скандал в мире Open Source: исключение российских разработчиков из ядра Linux
Недавние события вокруг разработчиков ядра Linux вызвали многочисленные споры и недоумение. Один из главных разработчиков ядра принял решение исключить 11 российских разработчиков, которые в некоторых случаях более 10 лет вносят свой вклад в проект.
Причина? «Потому что российские разработчики и Россия». 🎤💥
Многие из уволенных уже долгое время живут за пределами России, но это не помогло им остаться в проекте. Линус Торвальдс, основатель Linux, пояснил ситуацию, но отклонился от обсуждения деталей, ссылаясь на указания юристов.
Некоторые участники сообщества начали задаваться вопросами: что же произошло на самом деле? Какова истинная причина исключений? В конце концов, такая ситуация ставит под сомнение принципы, на которых строится open source более 25 лет.
Важно отметить, что Linux Foundation заявлял о нейтралитете open source в политике, но выводы, сделанные в этом случае, ставят это под сомнение. 🤔
На фоне этой ситуации, участники сообщества чувствуют напряжение и недоумение. Так ли просто развенчать все принципы открытости и сотрудничества, на которых была основана вся экосистема?
Niwe Code
#News #Linux Скандал в мире Open Source: исключение российских разработчиков из ядра Linux Недавние события вокруг разработчиков ядра Linux вызвали многочисленные споры и недоумение. Один из главных разработчиков ядра принял решение исключить 11 российских…
#News #Linux
В списке рассылки сообщества разработчиков Linux вышло официальное заявление разработчика «Байкал Электроникс» Сергея Сёмина по поводу исключения из списка мейнтейнеров Linux.
В своём письме Сергей сообщил, что после случившегося он потерял мотивацию для продолжения дальнейшего участия в разработке ядра, а попытки получить у вышестоящего мэйнтенера более подробную информацию о причине удаления не прояснили ситуацию - в ответе было лишь извинение, упоминание санкций, сожаление о невозможности что-либо сделать и совет обратиться к юристу своей компании. При этом Сергей уже более года участвует в разработке ядра только как волонтёр, а не как оплачиваемый работник. За время работы в сообществе Сергей отправил 518 патчей, прорецензировал 253 патча и принял участие в тестировании 80 патчей.
Данный инцидент показывает, что в любой человеческой деятельности есть доля (всё) политики.
Fuck The Linux Foundation!🐧
В списке рассылки сообщества разработчиков Linux вышло официальное заявление разработчика «Байкал Электроникс» Сергея Сёмина по поводу исключения из списка мейнтейнеров Linux.
В своём письме Сергей сообщил, что после случившегося он потерял мотивацию для продолжения дальнейшего участия в разработке ядра, а попытки получить у вышестоящего мэйнтенера более подробную информацию о причине удаления не прояснили ситуацию - в ответе было лишь извинение, упоминание санкций, сожаление о невозможности что-либо сделать и совет обратиться к юристу своей компании. При этом Сергей уже более года участвует в разработке ядра только как волонтёр, а не как оплачиваемый работник. За время работы в сообществе Сергей отправил 518 патчей, прорецензировал 253 патча и принял участие в тестировании 80 патчей.
Данный инцидент показывает, что в любой человеческой деятельности есть доля (всё) политики.
Fuck The Linux Foundation!
Please open Telegram to view this post
VIEW IN TELEGRAM