#Other #Start
Канал создан для выброса моихважных мыслей касательно вещей в IT индустрии + некоторого обучения в данной сфере. В своей задаче я ставлю продвижение разных тем в юмористическом стиле.
Сегодня нам доступно множество различной информации, особенно в нашей любимой "айтишечке". А есть ли шанс того что скоро та форма обучения которая сегодня работает, через 2-3 года заменит GPT?
Возможно... Но нет:
Канал создан для выброса моих
Сегодня нам доступно множество различной информации, особенно в нашей любимой "айтишечке". А есть ли шанс того что скоро та форма обучения которая сегодня работает, через 2-3 года заменит GPT?
Возможно... Но нет:
1. Лингвистическая система GPT может ответить на короткие ответы достаточно хорошо, по типу: "как установивт виндовс??". Но когда ей задаешь вопрос из ряда: "Как работает Асинхронность в JavaScript?" у гпт случается нервных срыв и дает очень неоднозначный ответ.
2. Нейросеть может придумать различные выдуманные источники информации, которые придуманы анунаками из далекой-далекой галактики.
3. "Ааа, скоро айтишники будут не нужны!! --ряяя нейронка всех заменит!! —пук-среньк" и другие знакомые всем высказывания. Спешу вас удивить: чтобы написать хороший сайт ТОЛЬКО с использованием нейросети, у людей ушло +-50 запросов. А кто же те люди которые составляют запросы? Правильно! Программисты.
❤2
#Education #Other
Поговорим на счет курсов:
Моё правильное и единственное мнение по этому поводу - обсирать человека только из-за того что он прошел курсы, а не "как фсе" прошел через образовательное учреждение, занятие весьма долбоебичесое.
1. В IT неважно, какой ты там курс прошел (Хоть от Торвальдса) и если человек не в состоянии сделать элементарные вещи по типу margin: left 10 px то тут вопросы уже не к курсу, а к человеку.
2. Хорошо, ты за год натаскал человека до уровня junior и что? На рыночке как бы нужен ещё и опыт который дают, но проектом Hello World ты никого не удивишь.
3. Курсы полезны если человек реально осознает что ему нужно от конкретной области: frontend, backend, DevOPS и.т.п. Имаджинируйте лицо вкатуна который зашел на сервис (*******) после рекламы какого-нибудь блогера и пытающийся понять "че мне изучать то? ЯЖ айтишнек - хочу 300к/н-нс"
По опровержениям моих слов залетайте в комментарии, если конечно будут нормальные аргументы
Поговорим на счет курсов:
Моё правильное и единственное мнение по этому поводу - обсирать человека только из-за того что он прошел курсы, а не "как фсе" прошел через образовательное учреждение, занятие весьма долбоебичесое.
1. В IT неважно, какой ты там курс прошел (Хоть от Торвальдса) и если человек не в состоянии сделать элементарные вещи по типу margin: left 10 px то тут вопросы уже не к курсу, а к человеку.
2. Хорошо, ты за год натаскал человека до уровня junior и что? На рыночке как бы нужен ещё и опыт который дают, но проектом Hello World ты никого не удивишь.
3. Курсы полезны если человек реально осознает что ему нужно от конкретной области: frontend, backend, DevOPS и.т.п. Имаджинируйте лицо вкатуна который зашел на сервис (
По опровержениям моих слов залетайте в комментарии, если конечно будут нормальные аргументы
❤2
#Education
В поисках идеального языка программирования
Вечный вопрос: "какой язык программирования учить? Java, чтобы почувствовать себя джедаем? Python, чтобы всё было максимально понятно, как в рецептах бабушки?" Выбор за вами.
Вообще сам вопрос уже тривиален, так как это аналогично спору: "2 > 1, но 2 < 3" и те и те правы, просто приоритеты расставлены немного по разные стороны. Вместо этих споров будет эффективнее на рандом взять ЯП и пойти его изучать (у меня так вышло с "C", хотя мой первый язык - Python)
Главное помнить: идеального языка не существует. Всё зависит от задачи. И кстати, ни один язык
В поисках идеального языка программирования
Вечный вопрос: "какой язык программирования учить? Java, чтобы почувствовать себя джедаем? Python, чтобы всё было максимально понятно, как в рецептах бабушки?" Выбор за вами.
Вообще сам вопрос уже тривиален, так как это аналогично спору: "2 > 1, но 2 < 3" и те и те правы, просто приоритеты расставлены немного по разные стороны. Вместо этих споров будет эффективнее на рандом взять ЯП и пойти его изучать (у меня так вышло с "C", хотя мой первый язык - Python)
Главное помнить: идеального языка не существует. Всё зависит от задачи. И кстати, ни один язык
не научит вас думать. Так что выбирайте язык, как пиццу: на свой вкус, но не забывайте о существовании разных добавок в виде фреймворков!❤1👍1🔥1
#Frontend #Backend
Frontend & Backend разработчики. Инь Ян it
Frontend и Backend разработчики — две стороны одной медали как кот и его хозяин, который всегда в поисках Wi-Fi. Один не может существовать без другого, иначе получится как ресторан без кухни — только официанты, которые не знают, что делать с пустыми тарелками.
Представьте, что это ресторан: Frontend — это официант и интерьер, которые видит клиент, а Backend — это кухня, где готовятся блюда. Клиент может восхищаться красивыми столиками и стильными стульями, но если на кухне повар забыл, как варить макароны, то все это великолепие быстро превратится в «почему я вообще сюда пришел?».
Frontend разработчик — этоненастоящий программист, который кроме покраски кнопок ничего делать не умеет тот, кто создает интерфейс, который привлекает и удобен для пользователей. Они работают с HTML, CSS и JavaScript (давайте айти бляди налетайте и говорите что JS это и Backand тоже, и вы будете правы) , чтобы сделать ваш сайт так, будто его только что вытащили из большого взрыва вселенной. Но помните, что даже самый красивый интерфейс не спасет вас от того, что кнопка «Купить» ведет на страницу с ошибкой 404.
С другой стороны, Backend разработчик — это тот, кто отвечает за "за кулисами". Они обрабатывают данные, пишут логику приложения и взаимодействуют с базами данных, используя языки типо Python, Ruby, Java или PHP. Они делают так, чтобы сервер не падал как(****) , как ваш друг на вечеринке, когда он выпил слишком много.
Так что, в следующий раз, когда frontend-разработчик скажет, что без красивого интерфейса сайт никто не оценит, а backend-разработчик будет утверждать, чтофронта можно посадить на бутылку, саманной Node JS, и без стабильной работы сервера и базы данных все пойдет прахом, помните: они оба правы! Гармоничное сочетание frontend и backend — это как идеальный тост с водкой: с одной рюмки получится только просто согреться.
Frontend & Backend разработчики. Инь Ян it
Frontend и Backend разработчики — две стороны одной медали как кот и его хозяин, который всегда в поисках Wi-Fi. Один не может существовать без другого, иначе получится как ресторан без кухни — только официанты, которые не знают, что делать с пустыми тарелками.
Представьте, что это ресторан: Frontend — это официант и интерьер, которые видит клиент, а Backend — это кухня, где готовятся блюда. Клиент может восхищаться красивыми столиками и стильными стульями, но если на кухне повар забыл, как варить макароны, то все это великолепие быстро превратится в «почему я вообще сюда пришел?».
Frontend разработчик — это
С другой стороны, Backend разработчик — это тот, кто отвечает за "за кулисами". Они обрабатывают данные, пишут логику приложения и взаимодействуют с базами данных, используя языки типо Python, Ruby, Java или PHP. Они делают так, чтобы сервер не падал как
Так что, в следующий раз, когда frontend-разработчик скажет, что без красивого интерфейса сайт никто не оценит, а backend-разработчик будет утверждать, что
Так что давайте ценить и тех, и других, ведь без них наш цифровой мир был бы похож на ресторан, где подают только воду и печенье. А кто захочет это есть?
❤1🔥1
#ITLifi
Жизненный цикл программиста: от нуля до бесконечности
1. Инициализация: "Какой же я крутой, сейчас все напишу за пару часов!" — на этом этапе программист чувствует себя богом программного обеспечения. Он уже представил как будет принимать благодарности с короной на голове и на конференциях разработчиков. Разве можно помешать этому юному энтузиасту?
2. Разработка: "Это сложнее, чем я думал" — на этом этапе жизнь начинает напоминать сложный квест RPG, где каждая новая функциональность замедляет процесс, где нужно чтобы каждая деталь работала без сбоев. Временами кажется что сам код дразнит: "А ты точно уверен, что я должен работать?"
3. Тестирование: "Почему это не работает???" — тут программное обеспечение решает сделать вид, что выполняет потайные танцы с байтами. Вместо наземного движения — лишь облачные баги. Программист, уставший от осознания что решение проблемы — это не просто перезагрузка системы, начинает задумываться о том чтобы обратиться к Астрологу: "Когда, наконец, пройдет этот Лунный цикл ошибок?"
4. Деплоймент: "Как это вообще заработало?" — после многочисленных попыток и безумных ночей код все же попадает в продакшн! Программист, смахивая слезу радости, начинает готовиться к шуточкам о том, что никакой день дурака никогда не кончится, если ваш код смог запуститься с первого раза. Вот она — магия работы кода!
5. Поддержка: "О нет, пожалуйста, не говори мне что это снова сломается." — на этом этапе программист начинает думать о жизни вне технологий. Может стать фермером? Нет, как только он задумывается приходит новая ошибка. Антикризисный план постиронии отказывается срабатывать и приходится показывать еще раз свою любовь к Ctrl+C и Ctrl+V.
6. Рефакторинг: "Ладно, сейчас я всё перепишу по новому." — здесь программист наконец приходит к решению о том, что собственный код нужно улучшить, ведь это своего рода терапия. Расположение переменных становится поводом для глубоких раздумий, а комментарии к коду начинают напоминать романтические заметки о страданиях.
Жизненный цикл программиста: от нуля до бесконечности
1. Инициализация: "Какой же я крутой, сейчас все напишу за пару часов!" — на этом этапе программист чувствует себя богом программного обеспечения. Он уже представил как будет принимать благодарности с короной на голове и на конференциях разработчиков. Разве можно помешать этому юному энтузиасту?
2. Разработка: "Это сложнее, чем я думал" — на этом этапе жизнь начинает напоминать сложный квест RPG, где каждая новая функциональность замедляет процесс, где нужно чтобы каждая деталь работала без сбоев. Временами кажется что сам код дразнит: "А ты точно уверен, что я должен работать?"
3. Тестирование: "Почему это не работает???" — тут программное обеспечение решает сделать вид, что выполняет потайные танцы с байтами. Вместо наземного движения — лишь облачные баги. Программист, уставший от осознания что решение проблемы — это не просто перезагрузка системы, начинает задумываться о том чтобы обратиться к Астрологу: "Когда, наконец, пройдет этот Лунный цикл ошибок?"
4. Деплоймент: "Как это вообще заработало?" — после многочисленных попыток и безумных ночей код все же попадает в продакшн! Программист, смахивая слезу радости, начинает готовиться к шуточкам о том, что никакой день дурака никогда не кончится, если ваш код смог запуститься с первого раза. Вот она — магия работы кода!
5. Поддержка: "О нет, пожалуйста, не говори мне что это снова сломается." — на этом этапе программист начинает думать о жизни вне технологий. Может стать фермером? Нет, как только он задумывается приходит новая ошибка. Антикризисный план постиронии отказывается срабатывать и приходится показывать еще раз свою любовь к Ctrl+C и Ctrl+V.
6. Рефакторинг: "Ладно, сейчас я всё перепишу по новому." — здесь программист наконец приходит к решению о том, что собственный код нужно улучшить, ведь это своего рода терапия. Расположение переменных становится поводом для глубоких раздумий, а комментарии к коду начинают напоминать романтические заметки о страданиях.
Таков никем незаметный жизненный цикл программиста. Это не просто работа — это целая философия, полная абсурда и только настоящие герои, готовые написать баги под звуки Рамштайна и распивать кофе с ночи до утра, могут с этим справиться. В конце концов код — это как хороший друг: он может ударить по ебалу, но мы все равно продолжаем дружить.
❤2
#Programming #Education
Типизация в программировании – это как выбор обуви: кто-то предпочитает строгие туфли, а кто-то — удобные кроссовки. Давайте проведем экскурсию по основным видам типизации чтобы понять, какая "обувь" подходит именно вам.
### 1. Статическая и динамическая типизация
Статическая типизация — это когда вы выбираете обувь заранее и носите её в течение всего вечера. В языках с такой типизацией как Java, C# и боже упоси C++, тип переменной определяется при компиляции. Другими словами вы не можете сказать: "Дам-ка своему целочисленному параметру немного покататься на серфе", а он сядет в угол и будет скучать, потому что не умеет ничего делать с плавающими числами.
Пример на Java:
Динамическая типизация — это когда вы надеваете кроссовки и можете бегать в любом направлении. Этот стиль типизации присутствует, например, в Python, PHP JavaScript. Здесь тип переменной определяется во время выполнения программы и вы можете делать с ней что угодно. Например, ваша переменная может сначала быть числом, а потом неожиданно стать строкой.
Пример на Python:
### 2. Сильная и слабая типизация
Сильная типизация — это как строгий дресс-код на корпоративе. Если вы пришли в шортах — придется стоять у двери. В языках с сильной типизацией, таких как Python или Java, вы не можете просто так взять и сложить число со строкой. Они будут смотреть на вас как на человека, пришедшего в костюме Billy Harrington'a на свадьбу.
Пример на Python:
Слабая типизация — это как неформальная вечеринка, где никто не обращает внимания на одежду. JavaScript, к примеру, позволяет вам складывать и объединять строки и числа в одно целое, как будто вы на многоженстве. Во общем тут вылезают все шуточки с JavaScript'иком когда вы складываете яблоки и варенье, а получаете в результате фиолетовый.
Пример на JavaScript:
### 3. Явная и неявная типизация
Явная типизация — это как если бы вы объявили всем на вечеринке какой у вас размер(ладно) обуви и каким цветом она в клетку. В языках с явной типизацией, таких как C или Java, программист сам указывает тип переменной.
Пример на C:
Неявная типизация — это как если бы вы пришли на вечеринку и никто даже не знал, сколько у вас пар обуви. В языках с неявной типизацией это происходит автоматически, обычно без вопросов.
Пример на Python:
### Заключение
Типизация — это как выбрать стиль жизни: каждый выбирает то, что ему удобнее. Какие-то языки требуют строгого соблюдения правил, а другие позволяют вам экспериментировать и нарушать границы. Главное — не забывайте выбирать подходящую "обувь" для своей программы, чтобы не убить ноги и не оказаться в неловкой ситуации.
Типизация в программировании – это как выбор обуви: кто-то предпочитает строгие туфли, а кто-то — удобные кроссовки. Давайте проведем экскурсию по основным видам типизации чтобы понять, какая "обувь" подходит именно вам.
### 1. Статическая и динамическая типизация
Статическая типизация — это когда вы выбираете обувь заранее и носите её в течение всего вечера. В языках с такой типизацией как Java, C# и боже упоси C++, тип переменной определяется при компиляции. Другими словами вы не можете сказать: "Дам-ка своему целочисленному параметру немного покататься на серфе", а он сядет в угол и будет скучать, потому что не умеет ничего делать с плавающими числами.
Пример на Java:
int number = 5; // Выбираем туфли
number = "Hello"; // Ой! Это больно. Компилятор говорит: "Так не пойдет!"
Динамическая типизация — это когда вы надеваете кроссовки и можете бегать в любом направлении. Этот стиль типизации присутствует, например, в Python, PHP JavaScript. Здесь тип переменной определяется во время выполнения программы и вы можете делать с ней что угодно. Например, ваша переменная может сначала быть числом, а потом неожиданно стать строкой.
Пример на Python:
number = 5 # Носим кроссовки
number = "Hello" # Теперь мы на вечеринке, и он стал артистом
### 2. Сильная и слабая типизация
Сильная типизация — это как строгий дресс-код на корпоративе. Если вы пришли в шортах — придется стоять у двери. В языках с сильной типизацией, таких как Python или Java, вы не можете просто так взять и сложить число со строкой. Они будут смотреть на вас как на человека, пришедшего в костюме Billy Harrington'a на свадьбу.
Пример на Python:
number = 5
result = number + "5" # Интересно, но Python говорит: "Нет, я на это не согласен."
Слабая типизация — это как неформальная вечеринка, где никто не обращает внимания на одежду. JavaScript, к примеру, позволяет вам складывать и объединять строки и числа в одно целое, как будто вы на многоженстве. Во общем тут вылезают все шуточки с JavaScript'иком когда вы складываете яблоки и варенье, а получаете в результате фиолетовый.
Пример на JavaScript:
let number = 5;
let result = number + "5"; // Ура! Мы получили 55, и никто не пострадал!
### 3. Явная и неявная типизация
Явная типизация — это как если бы вы объявили всем на вечеринке какой у вас размер
Пример на C:
int number = 5; // Явное заявление о своих намерениях
Неявная типизация — это как если бы вы пришли на вечеринку и никто даже не знал, сколько у вас пар обуви. В языках с неявной типизацией это происходит автоматически, обычно без вопросов.
Пример на Python:
number = 5 # Да, это число, вы даже не спрашивали!
### Заключение
Типизация — это как выбрать стиль жизни: каждый выбирает то, что ему удобнее. Какие-то языки требуют строгого соблюдения правил, а другие позволяют вам экспериментировать и нарушать границы. Главное — не забывайте выбирать подходящую "обувь" для своей программы, чтобы не убить ноги и не оказаться в неловкой ситуации.
❤1
#ITLife
Любовь и ненависть к фреймворкам
Фреймворки в программировании – это как мимолетный роман: они могут вдохновлять и поднимать тебе настроение, но в конечном итоге часто остаются с тобой только после отвратительного завтрака. 🤔 Давайте откровенно: с фреймворками мы переживаем целую гамму эмоций. Вот несколько стадий нашей любови:
1. Этап влюбленности:
- "С новым фреймворком я стану непобедим!" – это именно тот момент, когда мы надеваем розовые очки и каждый элемент кажется идеальным. Встретив стильные документы и «умные» функции, мы говорим: "Как же это круто!" 💖
2. Романтический запал:
- «Проект выйдет за неделю, Я освою его на раз-два!» – и тут наивный оптимизм встречается с реальностью. Через два дня мы уже только изучаем как настройка конфигурации может превратиться в сложную головоломку. И тут начинает приходить осознание: каждый казус – это не только твой, но и фреймворка.
3. Первая измена:
- "Почему каждая новая версия ломает всё что работало раньше?" – вот вопрос который мучает нас, как мука по утрам. Но отчаявшись мы идем искать "чела из стаковерфлоу", чтобы выполнить одну строку кода, пока пробуем "накатить" обновления.
4. Черная полоса:
- "Кто придумал этот фреймворк, и где я могу закопать его создателей?" – в этот момент мы начинаем проклинать всех, кто когда-либо касался клавиатуры, при этом осознавая что проблема, возможно, в самих нас. И если фреймворк запрещает мне писать приложения с минимальными усилиями, то я должен выставить его на всеобщее посмешище, рядом с недо-питонистами
5. Период смирения:
- "Наверняка, он всё равно его улучшит!" – тут как в отношений, мы идем на компромисс. Начинаем изучать документацию глубже, учим новые фреймворки, но и не забываем при этом залипать на обсуждениях о том, какой фреймворк все-таки лучший.
6. Собрание с сообществом:
- Фреймворки как вино: "А какой у вас любимый?" – и тут начинается самая настоящая битва уважаемых алкашей-программистов в дискуссиях с фанатами React, Vue и Angular! Но по сути все мы примерно одни и те же в плане разочарования и блаженства от изнасилования.
7. Финал:
- В итоге фреймворки – это как хорошие друзья: иногда они могут дико бесить, но без них ты понимаешь – жизнь была бы слишком скучной. Вот и выбирай: будет это любовь, ненависть или другой маневр, но одного не отнять – фреймворки сделали наше программирование ярким, хотя и утомительным! 🍷👩💻
Любовь и ненависть к фреймворкам
Фреймворки в программировании – это как мимолетный роман: они могут вдохновлять и поднимать тебе настроение, но в конечном итоге часто остаются с тобой только после отвратительного завтрака. 🤔 Давайте откровенно: с фреймворками мы переживаем целую гамму эмоций. Вот несколько стадий нашей любови:
1. Этап влюбленности:
- "С новым фреймворком я стану непобедим!" – это именно тот момент, когда мы надеваем розовые очки и каждый элемент кажется идеальным. Встретив стильные документы и «умные» функции, мы говорим: "Как же это круто!" 💖
2. Романтический запал:
- «Проект выйдет за неделю, Я освою его на раз-два!» – и тут наивный оптимизм встречается с реальностью. Через два дня мы уже только изучаем как настройка конфигурации может превратиться в сложную головоломку. И тут начинает приходить осознание: каждый казус – это не только твой, но и фреймворка.
3. Первая измена:
- "Почему каждая новая версия ломает всё что работало раньше?" – вот вопрос который мучает нас, как мука по утрам. Но отчаявшись мы идем искать "чела из стаковерфлоу", чтобы выполнить одну строку кода, пока пробуем "накатить" обновления.
4. Черная полоса:
- "Кто придумал этот фреймворк, и где я могу закопать его создателей?" – в этот момент мы начинаем проклинать всех, кто когда-либо касался клавиатуры, при этом осознавая что проблема, возможно, в самих нас. И если фреймворк запрещает мне писать приложения с минимальными усилиями, то я должен выставить его на всеобщее посмешище, рядом с недо-питонистами
5. Период смирения:
- "Наверняка, он всё равно его улучшит!" – тут как в отношений, мы идем на компромисс. Начинаем изучать документацию глубже, учим новые фреймворки, но и не забываем при этом залипать на обсуждениях о том, какой фреймворк все-таки лучший.
6. Собрание с сообществом:
- Фреймворки как вино: "А какой у вас любимый?" – и тут начинается самая настоящая битва уважаемых алкашей-программистов в дискуссиях с фанатами React, Vue и Angular! Но по сути все мы примерно одни и те же в плане разочарования и блаженства от изнасилования.
7. Финал:
- В итоге фреймворки – это как хорошие друзья: иногда они могут дико бесить, но без них ты понимаешь – жизнь была бы слишком скучной. Вот и выбирай: будет это любовь, ненависть или другой маневр, но одного не отнять – фреймворки сделали наше программирование ярким, хотя и утомительным! 🍷👩💻
❤1
#meme
Мне кажется вы стали забывать, кто тут настоящий хозяин программирования. Привыкли тут на меня лить помои и думаете я это просто так оставлю и ничего не сделаю вам в ответ?
Поздравляю, у вас получилось добиться полного разрыва моего клапана.
Да я код писал еще до того, как некоторые из вас под столом ползали; рефакторил такой чудовищный говнокод что вы даже представить себе не сможете; да у меня есть своя нейронка, которая обрабатывает столько информации, что Microsoft будет курить в сторонке.
И все потому что я - киберприрожденный. Установка ебашить код заложена в моих генах, клавиатура - мой меч, моя квалификация позволяет не только интерпретировать кофеин в машинные коды, но и параллельно разъебывать Мурыча и Соера. Таких избранных как я, существует единицы во всем мире и вы после всего этого смеете писать про меня всякие гадости?
Ну все ребята, вы у меня допрыгались. Щас, щас я все вам выскажу....
Мне кажется вы стали забывать, кто тут настоящий хозяин программирования. Привыкли тут на меня лить помои и думаете я это просто так оставлю и ничего не сделаю вам в ответ?
Поздравляю, у вас получилось добиться полного разрыва моего клапана.
Да я код писал еще до того, как некоторые из вас под столом ползали; рефакторил такой чудовищный говнокод что вы даже представить себе не сможете; да у меня есть своя нейронка, которая обрабатывает столько информации, что Microsoft будет курить в сторонке.
И все потому что я - киберприрожденный. Установка ебашить код заложена в моих генах, клавиатура - мой меч, моя квалификация позволяет не только интерпретировать кофеин в машинные коды, но и параллельно разъебывать Мурыча и Соера. Таких избранных как я, существует единицы во всем мире и вы после всего этого смеете писать про меня всякие гадости?
Тьфу на вас! Все вам рофлы, все вам приколы...Ну все ребята, вы у меня допрыгались. Щас, щас я все вам выскажу....
🔥2💯1
#Python #meme
Вот взять, например, Петухончиков (Питонисты, Python):
Ну что вы маленькие, вжались в свои кресла? Страшно вам!? Терпите...
Все питухончики это неиронично отсталые орангутанги не сумевшие освоить нормальный ЯП; Вот что-то я не вижу как на вашем мониторе обучается нейросетка, хотя обмазались своим "
Ой, а что там с многопоточностью? Все скриптики у питонистов невероятно медленные, а все потому что GIL может работать только в одном потоке, вот ведь не задача..? И я уже молчу про проблему релизов. Не обхаркал отказ в пользу второй версии Python только ленивый, а про мажорные обновления в Python 3 и несовместимости библиотек как-то принято молчать; к примеру:
Пакеты с пакетами того же матана и нейросеток. Лично для меня загадка что можно блять такого накодить в библиотеке для матана чтобы она была несовместима с интерпретатором 3.15 и 3.16
Всем же известно, что у каждого не уважающего себя питухонера установлено по 10-15 версий интерпретаторов одновременно.
Вот взять, например, Петухончиков (Питонисты, Python):
Ну что вы маленькие, вжались в свои кресла? Страшно вам!? Терпите...
Все питухончики это неиронично отсталые орангутанги не сумевшие освоить нормальный ЯП; Вот что-то я не вижу как на вашем мониторе обучается нейросетка, хотя обмазались своим "
компуктер скайнс" и убеждаете что как это все важно для индустрии в целом. Вечно хейтите С'и подобные языки, хотя сами тихо ночью плачете в подушку из-за индентации, ведь эту шляпу могло придумать только самое опущенное айтишное сознание; а все остальные молча решили схавать пробелы как часть синтаксиса языка.Ой, а что там с многопоточностью? Все скриптики у питонистов невероятно медленные, а все потому что GIL может работать только в одном потоке, вот ведь не задача..? И я уже молчу про проблему релизов. Не обхаркал отказ в пользу второй версии Python только ленивый, а про мажорные обновления в Python 3 и несовместимости библиотек как-то принято молчать; к примеру:
Пакеты с пакетами того же матана и нейросеток. Лично для меня загадка что можно блять такого накодить в библиотеке для матана чтобы она была несовместима с интерпретатором 3.15 и 3.16
Всем же известно, что у каждого не уважающего себя питухонера установлено по 10-15 версий интерпретаторов одновременно.
Все это выглядит как ебучий цирк, хотя сами петушары не перестают всем доказывать что у них самое удобное окружение для разработки. Да-да, утешайте себя пока я насмехаюсь над вами.
❤1
#JavaScript #meme
Так, кто там у нас следующий? Ага, все тонконогие джавастриптезеры (JavaScipt)
Все они пропитаны комплексом неполноценных чмонек на столько, что из-за этого готовы затащить какую угодно херню в браузер лишь бы выглядеть понтово в глазах других разрабов. Начиная от различных компиляторов древних версий EcmaScript до всяких ёбо изобретений типа TypeScript и прочего говна, но как бы малятки не старались избавиться от позорного клейма - проблема в конечном итоге в том, что все их потоки компилируются в тормазутый JS.
Даже немного жалко этих ребят, ведь у этих смузихлёбов просто нету других альтернатив((( Ирония судьбы в том, что JS
Так, кто там у нас следующий? Ага, все тонконогие джавастриптезеры (JavaScipt)
Все они пропитаны комплексом неполноценных чмонек на столько, что из-за этого готовы затащить какую угодно херню в браузер лишь бы выглядеть понтово в глазах других разрабов. Начиная от различных компиляторов древних версий EcmaScript до всяких ёбо изобретений типа TypeScript и прочего говна, но как бы малятки не старались избавиться от позорного клейма - проблема в конечном итоге в том, что все их потоки компилируются в тормазутый JS.
Даже немного жалко этих ребят, ведь у этих смузихлёбов просто нету других альтернатив((( Ирония судьбы в том, что JS
это единственный ЯП для покраски кнопок и ЯП, который может простить все ваши грязные, измазанные говном ручки в ошибках. Хочу сказать вам что другие разрабы настолько не уважают вас, что чисто по приколу чтобы поугарать над вами омежками, специально создают несовместимые стандарты, парсеры, интерпретаторы и в конечном итоге Браузеры.А что вы им сделаете!? Да ничего! Вы можете только смотреть и не вмешиваться в процесс, тихонечко сидеть на кресле в углу комнаты
❤1🗿1
#C #meme
Сишники (С). Древнепердящие душнилы очевидности. По определению не могут быть моложе 50 лет; даже если тебе 18 и ты пишешь на С - на самом деле тебе полтинник, разлогинься, достояние пенсионного фонда. Деды настолько преисполнились в своём байтодрочестве что частенько забывают о стандартных принципах гигиены. А еще чаще других особей заявляют о том, что парадигма "n" не нужна, ну и с учетом их почтенного возраста скорее всего я мог им уступить место в автобусе
Сишники (С). Древнепердящие душнилы очевидности. По определению не могут быть моложе 50 лет; даже если тебе 18 и ты пишешь на С - на самом деле тебе полтинник, разлогинься, достояние пенсионного фонда. Деды настолько преисполнились в своём байтодрочестве что частенько забывают о стандартных принципах гигиены. А еще чаще других особей заявляют о том, что парадигма "n" не нужна, ну и с учетом их почтенного возраста скорее всего я мог им уступить место в автобусе
🔥1💯1
#Education
Вот знаете, существуют люди, которые не умеют гуглить информацию? Ну ничего, не грустите, этот гайд специально для вас, малятки:
Начнём с основ: Если ваш запрос выглядит как "dotnet работа дома", то, возможно, стоит уже подтянуть логику запросов. Не надо писать текстами в духе романов — лучше конкретика. Например: "установить dotnet на pc". Просто и ясно.
Минус-слова — ваши друзья: Если вас задолбали посторонние сайты и мусорная информация, используйте знак "минус". Пишете что-то вроде: "Лучший ноутбук для работы -игры". Всё, проблема решена, и вы увидите только то, что нужно.
Кавычки, или "я не знаю, как это называется": Если вы ищете что-то конкретное, например, точную фразу или название, обрамите её кавычками. Например: "цитата день рождения король лев". Не в кавычках — улетите в абстракцию, в кавычках — попадёте точно в цель.
Или это, или то (через палочку): Если ты до конца не уверен, как правильно называется то, что ищешь, пиши с вариантом через палочку: "лапша вок | ресторан". Гугл найдет и то, и это.
Не бойтесь уточнять: Сначала вводите общий запрос, а потом уточняйте. "Ремонт ноутбука", затем "ремонт ноутбука Иркутск", а потом уже "ремонт ноутбука Lenovo Иркутск недорого". Это как с фразами в жизни — чем конкретнее, тем лучше.
Смотрите на даты: Запомните, малятки, информация имеет срок годности. В 2024 году открывать гайд по "новым технологиям" от 2017-го — это как хлеб с плесенью жевать.
Используйте поиск по сайтам: Не знаете, как найти что-то конкретное на любимом сайте? Гуглите так: "site:сайт.ру ваш запрос". Вот так: "site
.com async python".
Ну всё, теперь вы профессиональный гуглер. Бегите, малыши, и просвещайтесь!
Вот знаете, существуют люди, которые не умеют гуглить информацию? Ну ничего, не грустите, этот гайд специально для вас, малятки:
Начнём с основ: Если ваш запрос выглядит как "dotnet работа дома", то, возможно, стоит уже подтянуть логику запросов. Не надо писать текстами в духе романов — лучше конкретика. Например: "установить dotnet на pc". Просто и ясно.
Минус-слова — ваши друзья: Если вас задолбали посторонние сайты и мусорная информация, используйте знак "минус". Пишете что-то вроде: "Лучший ноутбук для работы -игры". Всё, проблема решена, и вы увидите только то, что нужно.
Кавычки, или "я не знаю, как это называется": Если вы ищете что-то конкретное, например, точную фразу или название, обрамите её кавычками. Например: "цитата день рождения король лев". Не в кавычках — улетите в абстракцию, в кавычках — попадёте точно в цель.
Или это, или то (через палочку): Если ты до конца не уверен, как правильно называется то, что ищешь, пиши с вариантом через палочку: "лапша вок | ресторан". Гугл найдет и то, и это.
Не бойтесь уточнять: Сначала вводите общий запрос, а потом уточняйте. "Ремонт ноутбука", затем "ремонт ноутбука Иркутск", а потом уже "ремонт ноутбука Lenovo Иркутск недорого". Это как с фразами в жизни — чем конкретнее, тем лучше.
Смотрите на даты: Запомните, малятки, информация имеет срок годности. В 2024 году открывать гайд по "новым технологиям" от 2017-го — это как хлеб с плесенью жевать.
Используйте поиск по сайтам: Не знаете, как найти что-то конкретное на любимом сайте? Гуглите так: "site:сайт.ру ваш запрос". Вот так: "site
.com async python".
Ну всё, теперь вы профессиональный гуглер. Бегите, малыши, и просвещайтесь!
❤2
#meme
Завтра ищете в интернете книжку "You Don’t Know JS" (серия книг) от Кайла Симпсона. Не переживайте, если что-то будет непонятно. Затем идете на MDN Web Docs изучать стандартную библиотеку JavaScript от корки до корки. Потом зубрите, именно, зубрите определения языка и стандартных библиотек — спецификацию ECMAScript, чтобы все термины и концепции отскакивали от зубов. Когда напишете свой первый промис и освоите асинхронное программирование, изучив теорию событий и коллбеков, скачиваете и изучаете любую библиотеку для работы с функциональным программированием, рекомендую Ramda или Lodash. Как только поймете, как использовать функции высшего порядка и композицию, можете идти дальше — вас ждет увлекательный мир функционального программирования в JavaScript.
Функции, замыкания, каррирование, монады, функторы, аппликативные функторы, промисы, генераторы, итераторы, реактивное программирование с RxJS, а также паттерны проектирования, такие как MVC, MVVM и Flux. Успех хиккующих выблѣдков или просто быдлокодеров типаJava-разработчиков, которые работают в крупных компаниях, не будут вас волновать, и уже через полгода вы будете получать такие предложения о работе,
что любой рекрутер будет в восторге от ваших навыков и опыта работы.
Рекомендации для всех двавастриптезеров:Завтра ищете в интернете книжку "You Don’t Know JS" (серия книг) от Кайла Симпсона. Не переживайте, если что-то будет непонятно. Затем идете на MDN Web Docs изучать стандартную библиотеку JavaScript от корки до корки. Потом зубрите, именно, зубрите определения языка и стандартных библиотек — спецификацию ECMAScript, чтобы все термины и концепции отскакивали от зубов. Когда напишете свой первый промис и освоите асинхронное программирование, изучив теорию событий и коллбеков, скачиваете и изучаете любую библиотеку для работы с функциональным программированием, рекомендую Ramda или Lodash. Как только поймете, как использовать функции высшего порядка и композицию, можете идти дальше — вас ждет увлекательный мир функционального программирования в JavaScript.
Функции, замыкания, каррирование, монады, функторы, аппликативные функторы, промисы, генераторы, итераторы, реактивное программирование с RxJS, а также паттерны проектирования, такие как MVC, MVVM и Flux. Успех хиккующих выблѣдков или просто быдлокодеров типа
что любой рекрутер будет в восторге от ваших навыков и опыта работы.
🔥1
#AI
Про нейронки
Журналюги обожают хайпить на нейросетях, которые якобы заменят всех программистов. Но почему они упускают тот факт, что нейросетки могут решить лишь около 14% примитивных задач с 88% ошибок?(Что цифры именно такие — чистая случайность, математики, молчите).
Да, конечно, вот-вот и всех программистов заменят. Какие же журналисты дегенераты. ChatGPT уже может их заменить, ведь нести полную чушь они умеют и сейчас, а вот хорошо кодить — нет.
На самом деле, нейросетки были внедрены в инструментарий еще до нынешнего бума с GPT и Midjourney: в IntelliJ IDEA и Visual Studio ИИ появился еще в 2019 году (хотя до сих пор не научился писать код за людей). Copilot от GitHub был разработан примерно тогда же, когда моего деда в Берлине штурмовал другой дед и под капотом там сменились уже не одни рельсы.. И что мы имеем? Рабочий код пузырьковой сортировки, скопированный с просторов Bag Overflow, написанный ночью пьяным студентом педагогического колледжа.
Максимум, на что нейросети способны в обозримые 20 лет — это быть жалкими рабами для разработчиков. Человек, который в принципе не умеет писать код, не сможет обычными запросами реализовать продукт, да и даже один из модулей этого продукта. Есть один малюсенький нюанс, который все постоянно забывают: чтобы пользоваться этим инструментарии, нужно понимать, как и что делать, чтобы объяснить тупой нейросети все тонкости реализации. В противном случае, как говорится, "без внятного ТЗ результат — ХЗ".
А знаете, как называются люди, которые могут объяснить блядской машине, что именно надо делать?
Про нейронки
Журналюги обожают хайпить на нейросетях, которые якобы заменят всех программистов. Но почему они упускают тот факт, что нейросетки могут решить лишь около 14% примитивных задач с 88% ошибок?
Да, конечно, вот-вот и всех программистов заменят. Какие же журналисты дегенераты. ChatGPT уже может их заменить, ведь нести полную чушь они умеют и сейчас, а вот хорошо кодить — нет.
На самом деле, нейросетки были внедрены в инструментарий еще до нынешнего бума с GPT и Midjourney: в IntelliJ IDEA и Visual Studio ИИ появился еще в 2019 году (хотя до сих пор не научился писать код за людей). Copilot от GitHub был разработан примерно тогда же, когда моего деда в Берлине штурмовал другой дед и под капотом там сменились уже не одни рельсы.. И что мы имеем? Рабочий код пузырьковой сортировки, скопированный с просторов Bag Overflow, написанный ночью пьяным студентом педагогического колледжа.
Максимум, на что нейросети способны в обозримые 20 лет — это быть жалкими рабами для разработчиков. Человек, который в принципе не умеет писать код, не сможет обычными запросами реализовать продукт, да и даже один из модулей этого продукта. Есть один малюсенький нюанс, который все постоянно забывают: чтобы пользоваться этим инструментарии, нужно понимать, как и что делать, чтобы объяснить тупой нейросети все тонкости реализации. В противном случае, как говорится, "без внятного ТЗ результат — ХЗ".
А знаете, как называются люди, которые могут объяснить блядской машине, что именно надо делать?
ПРОГРАММИСТЫ! Они просто используют язык программирования вместо простого человеческого. И я уж молчу про особенно сложные кейсы, которые требуют ответственности. Обожаю находчивость ИИ в выдумывании всяких несуществующих библиотек, которые, о чудо, идеально решают твою проблему. Осталось только установить все зависимости и написать три строчки кода. Как же это восхитительно(((🔥1
#Linux
Вот знаете, само ядро Linux — это настоящее произведение искусства в мире IT. Без него Интернет, каким мы его знаем, мог бы остаться на уровне локальной сети подземного игрового клуба Иркутска. Трудно представить себе сервер, который бы не работал на каком-нибудь дистрибутиве на базе GNU/Linux. Но, бля, когда дело доходит именно до GNU и всей этой шайки задротов-программистов-любителей десктопного ПО, то в репозиториях начинается сущий кошмар.
За 20 с лишним лет эти ребята не смогли создать ни одного нормального дистрибутива, который был бы лучше Windows или macOS для десктопов. Почему так? Сейчас объясню, и заодно поделюсь своим опытом использования Linux.
Если кому-то захочется сказать, что я идиот, то знайте: я управляю таксопарком из 5 виртуальных машин на Linux, за свою жизнь перенастроил столько серверов, что у терминала начинается течка между приглашением и именем пользователя. Именно на таких людях как я, держится весь грёбаный Интернет, позволяя гонять терабайты низкосортной порнухи и котиков за нано-секунды.
Проблема Linux'a одна, и она очень проста: ничего никогда не работает "из коробки". Ты не можешь просто накатить дистрибутив и начать им пользоваться — всегда найдутся проблемы, и их сначало будет дохрена, а потом опять дохрена. И так по кругу.
Можно подумать: "Ну ладно, поставил, пофиксил — и пользуешься хорошей ОС". Но проблема в том, что это бессмысленно. Linux не даёт никаких преимуществ, а наоборот, лишь проигрывает в возможностях и удобстве по сравнению с другими ОС.
Вот мой список проблем, с которыми я столкнулся за месяц:
И это лишь верхушка айсберга...
Я могу продолжать этот список до бесконечности, но пост не резиновый. В общем, поставив себе Linux, ты не получишь ничего, кроме огромного ЧСВ до небес, а будешь только страдать.
Отдельно хочется упомянуть секту свидетелей обновлений: патчи на Linux приходят каждый день, и их блять надо устанавливать вручную через любимый терминал. В этом вашем Windows они хотя бы сваливаются раз в месяц и ставятся при перезагрузке, не доставая тебя каждый день.
И это даже не затрагивая софт. В большинстве случаев на Linux он портирован так, что даже макака из училища Усть-Залупинска справилась бы лучше.
Весь нужный софт для Linux можно спокойно запускать на Windows через WSL. Вторая версия полностью решила проблему совместимости, и нет такого дерьма, которое я бы не смог запустить на Windows.
Так что давайте, объясните мне, в чём я не прав, особенно жду ответ от секты пользователей
Вот знаете, само ядро Linux — это настоящее произведение искусства в мире IT. Без него Интернет, каким мы его знаем, мог бы остаться на уровне локальной сети подземного игрового клуба Иркутска. Трудно представить себе сервер, который бы не работал на каком-нибудь дистрибутиве на базе GNU/Linux. Но, бля, когда дело доходит именно до GNU и всей этой шайки задротов-программистов-любителей десктопного ПО, то в репозиториях начинается сущий кошмар.
За 20 с лишним лет эти ребята не смогли создать ни одного нормального дистрибутива, который был бы лучше Windows или macOS для десктопов. Почему так? Сейчас объясню, и заодно поделюсь своим опытом использования Linux.
Если кому-то захочется сказать, что я идиот, то знайте: я управляю таксопарком из 5 виртуальных машин на Linux, за свою жизнь перенастроил столько серверов, что у терминала начинается течка между приглашением и именем пользователя. Именно на таких людях как я, держится весь грёбаный Интернет, позволяя гонять терабайты низкосортной порнухи и котиков за нано-секунды.
Проблема Linux'a одна, и она очень проста: ничего никогда не работает "из коробки". Ты не можешь просто накатить дистрибутив и начать им пользоваться — всегда найдутся проблемы, и их сначало будет дохрена, а потом опять дохрена. И так по кругу.
Можно подумать: "Ну ладно, поставил, пофиксил — и пользуешься хорошей ОС". Но проблема в том, что это бессмысленно. Linux не даёт никаких преимуществ, а наоборот, лишь проигрывает в возможностях и удобстве по сравнению с другими ОС.
Вот мой список проблем, с которыми я столкнулся за месяц:
1. Не работающие аппаратные элементы. Некоторые клавиши fn1-fn12 просто игнорируются, потому что драйверов или софта для них под Linux нет.
2. HiDPI-разрешение. ОС может и отображаться нормально, но софт — чаще всего нет. Где-то не подстроилось совсем, где-то — частично.
3. Pulseaudio. Звук завис? Перезапусти Pulseaudio. Воткнул наушники? Перезапусти Pulseaudio. Не работает Bluetooth? Угадайте... да, перезапусти Pulseaudio!
4. Графика. Представьте, в 2024 году ноутбук на Linux не умеет автоматически переключаться на дискретную видеокарту. Хочешь это сделать? Перезапусти Linux!
И это лишь верхушка айсберга...
Я могу продолжать этот список до бесконечности, но пост не резиновый. В общем, поставив себе Linux, ты не получишь ничего, кроме огромного ЧСВ до небес, а будешь только страдать.
Отдельно хочется упомянуть секту свидетелей обновлений: патчи на Linux приходят каждый день, и их блять надо устанавливать вручную через любимый терминал. В этом вашем Windows они хотя бы сваливаются раз в месяц и ставятся при перезагрузке, не доставая тебя каждый день.
И это даже не затрагивая софт. В большинстве случаев на Linux он портирован так, что даже макака из училища Усть-Залупинска справилась бы лучше.
Весь нужный софт для Linux можно спокойно запускать на Windows через WSL. Вторая версия полностью решила проблему совместимости, и нет такого дерьма, которое я бы не смог запустить на Windows.
Так что давайте, объясните мне, в чём я не прав, особенно жду ответ от секты пользователей
Arch Linux — это те ещё "долбоёбы" в мире Linux, хотя куда уже хуже?#startap #Education
Ну что, малята, предлагаю вам сделку: я делаю из вас долларовых миллиардеров, а вы потом скидываетесь мне по миллиончику. Идёт? Отлично.
Давайте я расскажу, как правильно делать стартап, чтобы потом жить на широкую ногу за счёт инвестиций какого-нибудь гоя из Кремниевой долины(хотя их называют инвесторами, но давайте смотреть правде в глаза) .
Кто я такой, чтобы рассказывать про стартапы? Очевидно — успешный стартапер. Мы с ребятами запилили проект, продали его инвесторам и теперь сидим довольные на долларовой горке. Сейчас я являюсь Генеральным директором этой глобальной транснациональной компании (хотя благодаря санкциям это "транснациональная" пока только на словах). А вообще, я стал техническим директором просто потому, что громко заявил об этом на одном из собраний. Единственное сопротивление было от чувака, который делал нам архитектуру, но его жалкое "эээ..." я успешно проигнорировал. В итоге под моим управлением от одной до двух тысяч человек(скорее два, чем тысяча) , но суть вы поняли.
Итак, как начинается стартап? Конечно, с идеи. Найти её несложно — каждый второй интернет-гений считает себя Илоном Маском, лопатой раздавая "революционные" идеи. И тут же эти "стартаперы" ищут людей, которые сделают всё за 50% от будущей прибыли (
Можно, конечно, замотивировать свою команду работать на вас, но для этого придётся доказать, что идея рабочая. Это как у нас: генеральный купил у школьника за 500 рублей архитектуру проекта и уверял, что, если следовать плану, стартап взлетит. Так что перед тем как искать кодеров для разработки 3D-игры-хен..., убедитесь, что ваша идея не полное фуфло.
Следующий шаг — планирование. Обычно все его пропускают и потом мочатся в штанишки. Вначале все суперзамотивированы, готовы Луну сдвинуть, а спустя две недели программист Алёша перестаёт отвечать, дизайнер Валера занят ЕГЭ. Почему так происходит? Потому что вафлер, который всё это затеял, скипнул этап планирования.
Чтобы такого не случилось, нужно сесть с командой, обдумать минимальную функциональную версию продукта, составить график (RoadMap), чётко прописать дедлайны и задачи для всех. Чёткое ТЗ уменьшает вероятность, что ваш стартап улетит в трубу на 50%.
Теперь о разделении доходов. Старая русская поговорка "не дели шкуру неубитого медведя" — это полнейший бред. Наши предки не разбирались в стартапах, так что их советы тут не работают. Делить деньги нужно на берегу. И если кто-то думает, что деление "поровну" — хорошая идея, то я вас разочарую.
В стартапе кто-то тащит и продаёт идею, а кто-то верстает HTML. Разве это равноценный вклад? Конечно, нет. В нормальных местах платят зарплату, и в стартапах тоже, только чаще всего — опционами.
Ну что, малята, предлагаю вам сделку: я делаю из вас долларовых миллиардеров, а вы потом скидываетесь мне по миллиончику. Идёт? Отлично.
Давайте я расскажу, как правильно делать стартап, чтобы потом жить на широкую ногу за счёт инвестиций какого-нибудь гоя из Кремниевой долины
Кто я такой, чтобы рассказывать про стартапы? Очевидно — успешный стартапер. Мы с ребятами запилили проект, продали его инвесторам и теперь сидим довольные на долларовой горке. Сейчас я являюсь Генеральным директором этой глобальной транснациональной компании (хотя благодаря санкциям это "транснациональная" пока только на словах). А вообще, я стал техническим директором просто потому, что громко заявил об этом на одном из собраний. Единственное сопротивление было от чувака, который делал нам архитектуру, но его жалкое "эээ..." я успешно проигнорировал. В итоге под моим управлением от одной до двух тысяч человек
Итак, как начинается стартап? Конечно, с идеи. Найти её несложно — каждый второй интернет-гений считает себя Илоном Маском, лопатой раздавая "революционные" идеи. И тут же эти "стартаперы" ищут людей, которые сделают всё за 50% от будущей прибыли (
то есть 50% от нуля). Но ни один нормальный человек не будет участвовать в этом цирке, потому что в 99% случаев идея — дерьмо.Можно, конечно, замотивировать свою команду работать на вас, но для этого придётся доказать, что идея рабочая. Это как у нас: генеральный купил у школьника за 500 рублей архитектуру проекта и уверял, что, если следовать плану, стартап взлетит. Так что перед тем как искать кодеров для разработки 3D-игры-хен..., убедитесь, что ваша идея не полное фуфло.
Следующий шаг — планирование. Обычно все его пропускают и потом мочатся в штанишки. Вначале все суперзамотивированы, готовы Луну сдвинуть, а спустя две недели программист Алёша перестаёт отвечать, дизайнер Валера занят ЕГЭ. Почему так происходит? Потому что вафлер, который всё это затеял, скипнул этап планирования.
Чтобы такого не случилось, нужно сесть с командой, обдумать минимальную функциональную версию продукта, составить график (RoadMap), чётко прописать дедлайны и задачи для всех. Чёткое ТЗ уменьшает вероятность, что ваш стартап улетит в трубу на 50%.
Теперь о разделении доходов. Старая русская поговорка "не дели шкуру неубитого медведя" — это полнейший бред. Наши предки не разбирались в стартапах, так что их советы тут не работают. Делить деньги нужно на берегу. И если кто-то думает, что деление "поровну" — хорошая идея, то я вас разочарую.
В стартапе кто-то тащит и продаёт идею, а кто-то верстает HTML. Разве это равноценный вклад? Конечно, нет. В нормальных местах платят зарплату, и в стартапах тоже, только чаще всего — опционами.
Оценку стартапа вам дадут акселераторы, инкубаторы и прочие инвесторские заведения. Так что, если не хотите просрать всё, придётся ходить по ним и торговать лицом.И последнее — управление. Это 70% успеха. Менеджмент решает, даже если у разработчиков всё валится из рук. Без сильного управленца стартап обречён на провал. Программистов, как бы сложно это ни было, можно заменить. А вот менеджмент — нет.
Так что, если чувствуете в себе силы стать "стартап-гендиром", готовьте свой план и свою команду.
🔥1
#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